|
From: Dave D. <dde...@es...> - 2006-04-10 17:46:43
|
Daniel J Sebald <dan...@ie...> writes:
> Dave Denholm wrote:
>
>> Beware that the x protocol (and so xlib) is mostly
>> asynchronous. Errors are usually sent asynchronously, like events.
>> It is possible to handle errors, just a little messy. I forget the
>> details, but you can use XSync() to force a round-trip to the
>> server. This way, you can guarantee that all errors have been
>> delivered for requests up to the sync.
> I'm somewhat familiar with XSetErrorHandler.
>
> Not sure this is directly related to the problem though. Could be.
>
I was replying mainly to
>> Shouldn't you just get an error return from the call to XSelectInput?
Just pointing out that xlib fns don't usually return errors. The error
gets delivered later.
I've just had a look at the 4.0 X code (that's the latest source tree
I happen to have lying around)
One thing that looks a bit odd : in DrawRotated, it has
prevErrorHandler = XSetErrorHandler(DrawRotatedErrorHandler);
...
XSetErrorHandler(prevErrorHandler);
However, because errors are delivered asynchronously, but
XSetErrorHandler is synchronous, the chances are that you are going to
remove the error handler before the errors have been delivered. You
probably need to either leave the error handler plumbed in
permanently, and use sequence numbers to figure out what to do, or do
an XSync() before removing the error handler. But this may have
changed since 4.0
I also disagree with the comments about
/* NOTE: The removing of plots via the ErrorHandler routine is rather
tricky. The error events can happen at any time during execution of
the program, very similar to an interrupt.
It's nowhere near as bad as that. The errors can only be delivered to
the program when xlib is actually reading from the socket. That can
only happen either when it is waiting for a reply to a round-trip
request, or when you are reading events.
( XSync() is a round-trip request, actually implemented a trivial
request that can't fail. Can't remember which one, now.)
dd
--
Dave Denholm <dde...@es...> http://www.esmertec.com
|