Re: Connect gnuplot_x11 to exterior application window

[Daniel J S. <dan...@ie...>]

Dave Denholm wrote:
> 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 hear you.  In thinking mode right now.

> 
> 
> 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

Got me on that one.  I don't know where this use of XSetErrorHandler comes from.  (Can't recall it from when I worked on that aspect of the system.)  I was referring to the other use of ErrorHandler in the code, dealing with safe removal of a plot from the list.

> 
> 
> 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.

I think it is.  I spent a lot of time on that code trying to dream up a safe way of maintaining the list.

> 
> 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.

I'm not sure that implies the problem doesn't exist.  The issue is the following.  The ErrorHandler is called in response to the "close window" or "destroy window" (whatever it is called) that comes from the system by pressing that little box with an x in it at the top right corner.

The core code of gplt_x11.c has pointers to elements in the linked list of plots.  If ErrorHandler asynchronously removes a plot from the linked list and the core code uses its pointer to attempt drawing or whatnot, it's a seg fault.  I tried many simpler solutions before the "queuing" approach, but seg faults were consistently happening on occasion.

It's the maintaining of the list that is the tricky part.  The bottom line, I think, is to make it so that the core code is the one to remove plots from the linked list.  And even with that concept, it isn't simple to make sure things aren't lost or repeated in the queue.

Dan