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;
}
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
