Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!agate!ucbvax!hplabs!hpcc05!hpsciz!masa
From: masa@hpsciz.sc.hp.com (Masayoshi Habu)
Newsgroups: comp.windows.x.motif
Subject: Re: XmUpdateDisplay - the little engine that couldn't?
Message-ID: <13270013@hpsciz.sc.hp.com>
Date: 18 Jun 91 15:59:21 GMT
Article-I.D.: hpsciz.13270013
References: <MONTNARO.91Jun17153835@spyder.crd.ge.com>
Organization: Hewlett-Packard, Santa Clara, CA
Lines: 14

In comp.windows.x.motif, montnaro@spyder.crd.ge.com (Skip Montanaro) writes:

    Can someone comment on my perception of the situation? Whether my ideas are
    right or wrong, are there any techniques I can use to remedy my problem?
    Currently I just execute several XFlush's in the client after the first
    XmUpdateDisplay call to slow the client down. Naturally, this doesn't always
    work either. (I could have the client sleep for awhile, but for how long?)

I have experienced similar problems. Instead of XFlush, I called XSync.
Calling a pair of XSync and XmUpdateDisplay once ot twice took care of
my problems. As you see, this depends on the relative speed of our server
and client. Asynchronous parallel processes give me interesting problems.

Masa