From: Daniel J S. <dan...@ie...> - 2004-09-28 09:11:03
|
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 |