Re: maximing/resizing multiple x11: change of palette

[Ethan M. <merritt@u.washington.edu>]

On Tuesday 28 September 2004 02:38 am, Daniel J Sebald wrote:
> Line 817... OK, I see that.  Let me think it over.  My point is that all 
> the graphics stuff in response to X events is done by gnuplot_x11 inside 
> this loop:
> 
>         do {
>         XNextEvent(dpy, &xe);
>         process_event(&xe);
>         } while (XPending(dpy));
> 
> Am I understanding correctly that with this configuration the X events 
> can come at any time, but they are processed in an orderly fashion?

They are processed in order, yes.  But each pass through the main loop
will either deal with input from the pipe or with a queue of X events,
whichever is seen first. The two types of input are asynchronous.

> I  don't think there are any events initiated by X that can suddenly change 
> current_plot or current_cmap, which are what the information coming 
> across the pipe pertains to.

current_cmap must be something you added, so I don't know 
how it is handled.  

But unless I am remembering incorrectly, everything else is subject to
arbitrary change because you can bind any operation at all to a hotkey,
and the hotkey is recognized and executed as an X event.  
Isn't that right? This is admittedly perverse, but consider the case
	bind K "set term x11 7; set palette gray; replot"

Now suppose I hit K in a plot window while your code is reading
from the pipe. Will your code survive have the terminal closed,
re-opened and replotted with a different palette in mid-stream?

> We'll just see how it behaves and if we can break it.

Race conditions can be very hard to find by trail and error.
You really need to think about these issues while designing
the code in the first place.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195