Re: Obscure timing issue

[Richard Frith-Macdonald]

On 9 Dec 2008, at 23:39, Wolfgang Lux wrote:

> At this point, the gui appears to highlight the clicked button. At  
> least
> the ktrace output shows that the process attempts to read the  
> directories
> ThemeTiles, ThemeTiles/German.lproj, and ThemeTiles/English.lproj in  
> the
> gui's Resources directory multiple times, which all don't exist on my
> system, and then it writes a lot of data to the X connection socket  
> (in
> fact, it is sending about 500 kByte to the server; this looks like  
> it is
> redrawing the whole open panel and not only the Cancel button). The  
> important
> point is that at the time when the backend starts writing the data  
> to the
> X server, the ButtonRelease event is available on the X socket and  
> read
> into the X event queue by the X library code. Thus, no data is  
> available
> on the X connection socket when the run loop invokes the poll or  
> select
> system call and it starts waiting for the next event ...

Ah ... so if I understand correctly, you are saying that the X library  
checks and reads from the socket at times *other* than when we call  
XPending() in the handler which deals with run loop events.  Thus  
there is a window between us checking for pending events and us  
telling the runloop to watch the socket, in which the x library can  
read the events we are expecting from the socket.

I think there is a possible workaround for this in our runloop code in  
gnustep-base ...
As well as the -receivedEvent:type:extra:forMode: method that the  
backend code uses to handle events, it can also implement the - 
runLoopShouldBlock: method to tell the run loop how to behave before  
doing the select/poll.

So it could be something like:

- (BOOL) runLoopShouldBlock: (BOOL*)trigger
{
  *trigger = YES;       //  Should trigger this event
 if (XPending(dpy) > 0)
    {
      return NO;        // Don't block
    }
  return YES;
}