Ethan Merritt wrote:
>On Monday 27 September 2004 03:27 pm, Daniel J Sebald wrote:
>
>
>>Ethan Merritt wrote:
>>
>>
>>
>>>I'm a bit worried about races if you mix scheme (a) with the replots
>>>done under scheme (b).
>>>
>>>
>>>
>>I thought I saw that the core of gnuplot of x11 looks at events and then
>>handles them, handles drawing commands, etc. So, I think the scenarios
>>you mention above should all complete before a next operation can take
>>place.
>>
>>
>
>I don't think so. The main loop does a select() at line 817 of gplt_x11.c
>that mixes input from the pipe (line 849) and from X events (line 844).
>I see nothing to stop an X event from slipping in between two successive
>reads from the input pipe.
>
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? 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.
But you are right that something must go awry if, say, a window is
closed when only half the plot information has been put through a pipe.
You probably don't remember, but we did once wonder what should happen
when the current_plot is closed. Should we make another plot current?
Or just set current_plot to NULL. We went with setting it to NULL,
which is probably the more wise thing to do. The reason is you can
react accordingly, e.g., open a new plot window (with the
"most_recent_plot_number", something we talked about a couple weeks
ago), or do nothing if current_plot is NULL until a new 'G' or 'N'
command comes along to redo a plot.
I think I'm getting off course here, but my point is that there does
seem to be graceful behavior for this.
>>That is, gnuplot_x11 is the one actually closing
>>plots and X windows, somewhere in its event cycle. The outside error
>>events are just requesting that gnuplot_x11 close windows, etc.
>>
>>
>
>Not be relevant to the current point, but that's not true either.
>Yes, if you type "q" or "ctrl-q" then it's gnuplot_x11 that actually closes
>the plot window. But if you select XKill or some window manager function
>to close the plot window then I think it's already gone by the time gnuplot_x11
>finds out about it.
>
OK, XKill. I've not investigated, but is the XKill the little box in
the upper right corner of an X window, with the 'x'? From what I
remember, pressing that button is what causes X to call the routine:
ErrorHandler(Display * display, XErrorEvent * error_event)
which queues up a plot to be removed, not too far after gnuplot_x11's X
processing loop above. (I'm watching the DEBUG commands in stderr to
verify this.) I'm sure there are other ways for X to close a window,
but until some X-Man (i.e., true superhero) pinpoints other ways, I'm
not compelled to hunt for them.
I see my window manager has a "kill app" associated with each window.
However, that doesn't kill a window, it kills the app that owns the
window and leaves gnuplot_x11 defunct.
We'll just see how it behaves and if we can break it.
Dan
|