[xcb] XCB polling and single-threadedness

[Bart Massey]

AFAIK, XCBPollEvent() should not cause a select() on the
socket, just non-blocking reads until empty.  But I agree
with Jamey's general architecture.  Nice catch!

	Bart

In message <1026034404.502.139.camel@zoo> you wrote:
> Hey all!
> 
> Good job, Andy. Unfortunately, XCBReadPacket doesn't work the way you
> think it does. Sorry. :) I've added some comments in an attempt to make
> future readers think it works the way it does. :)
> 
> For a complete XCBPollEvent implementation - which I need for XCL
> anyway, so I'm glad this came up - it should also cause a non-blocking
> read of the socket. XCBWait won't do, because it calls select and asks
> it to wait forever. XCBReadEvent won't do, because (and here was the
> confusion) it never accesses the socket at all.
> 
> As it happens, PollEvent can work without this non-blocking read - I've
> updated test/main.c to call it occasionally - but applications may fail
> in mysterious ways until it's fixed.
> 
> The best solution is probably to make the select timeout parameter be
> passed to XCBWait. Current callers would pass a 0 there, while PollEvent
> would pass the address of a struct indicating a 0 second timeout.
> Perhaps you could take care of this too, Andy?
> 
> Thanks!
> 
> -Jamey
> 
> On Sat, 2002-07-06 at 18:58, Andy Howe wrote:
> > XCBGenericEvent *XCBPollEvent(XCBConnection *c);
> > 
> > If there are any events currently in the queue, the first event is
> > returned. Otherwise, a null pointer is returned. Basicly, it works the
> > same as XCBWaitEvent() except it returns null instead of waiting for an
> > event if there is not one currently in the queue.
> -- 
> Jamey Sharp <jamey@sharp.ath.cx> - http://jamey.is.dreaming.org/
> 
> 
> _______________________________________________
> xcb mailing list
> xcb@nickle.org
> http://nickle.org/mailman/listinfo/xcb