Re: Problems with while/splot/wxt

[Ethan A M. <sf...@us...>]

On Friday, 13 February, 2015 13:37:40 Philipp K. Janert wrote:
> On Fri, 13 Feb 2015 12:52:50 -0800
> Ethan A Merritt <sf...@us...> wrote:
> 
> Wanting to exit a loop (whether it's technically 
> infinite or merely long running) is not a programming 
> error. 
> 
> I think what you are saying is that a user
> should not expect gnuplot to recover gracefully
> if a loop is terminated by other means than the
> loop condition, and that therefore the user
> MUST provide such an exit condition. 

No, what I said was that an external kill signal
(control-C from the terminal in this case) is not
a normal way to interact with a program, and in 
particular is not a normal way to exit a program loop.

Providing an explicit end-loop condition in the "while"
clause is certainly one very common method for normal exit.
Many languages also offer "break" or "goto" or "return".
Gnuplot doesn't currently support break or goto, but 
in a loaded script using "exit" acts as a "return to the 
caller/loader".  So another possible loop would be

  while (1) {
     if (done) exit
     plot <stuff>
  }
  
> I am not sure I follow the logic of your last
> paragraph entirely, though. Why "pause 0.01"?
> Why not "pause 0.0001"? Or "pause 1", for that
> matter?

Why not indeed?  Use whatever seems appropriate.

> How can I (as the user) know what kind 
> of delay is enough for wxt (?) to catch up with 
> gnuplot's core? If gnuplot overflows an internal
> data structure or fails to respond to keyboard
> events, then that's a programming error, not a
> user error. 

I think you misunderstand what is happening.

We're not talking about an internal gnuplot data structure.
We're talking about whatever inter-process communication
protocol is used by the local wxgtk graphics library.
On linux that happens to be libpthread, but I imagine
it's different on Windows or OSX or whatever.
The system will buffer the information sent over that
communications channel, gradually consuming system resources
if the reader doesn't keep up with the writer and the
writer doesn't block.  I suppose eventually you might run
out of memory or disk cache, but it would take a long time.
It's exactly analogous to running this loop after
"set term pdf; set output 'file.pdf'".  Eventually that
output file will use up all your allowed disk space.  
But it's your own fault, not gnuplot's.

When the stop request ('d' keyboard event in my sample script)
is delivered to gnuplot, it stops writing new commands into the
communication channel.  But the channel may still be bloated 
with previously written commands that the reader end will take
some time to process.  Stuffing yet another command into the
channel at the end of the queue to tell the reader end
"you can stop now" will not help.
To forcibly terminate processing by the reader end would require
some out-of-band signal or a more drastic action like
destroying/resetting the communication channel. 

> Or is it a fact that any loop that
> needs to respond to a user event MUST contain
> pause? 

No.  The response is [supposed to be] immediate regardless of
whether the loop contains a pause.  The purpose of the
pause is to prevent gnuplot from running faster than 
your graphics display can keep up with.

> Again: that's totally acceptable - it it's
> communicated as such. Since I did not find that
> info in the docs, I am asking here - where else?

Perhaps the key point to make clear is simply that there
are two "black boxes" involved here.  One is what we (the 
developer's mailing list) usually call the core.  The other
box is the graphics display driver, which depending on the
terminal type may be a separate thread (e.g. wxgtk on linux) or
a separate program (e.g. gnuplot_x11 or gnuplot_qt) or some
more circuitous pathway (gnuplot->[pdf file]->okular).
It is easily possible for the second black box to keep
functioning even after the first one (gnuplot core) is
finished.  That's the normal case for ps/pdf/png/svg output.
It is also possible for qt or x11 if you use the "persist"
option.  You can even reconnect a later gnuplot core session
(black box #1) to the previous but still running output
session (black box #2).

Trying to document what will happen if you use external commands
to clobber one of these boxes seems pointless to me.
If you reach a state where  "killall --signal KILL gnuplot"
is required, the bad stuff has already happened.
If that state is due to a bug then sure, let's try to identify
and fix it.  But responding to the kill signal is not itself a bug.


	Ethan


> Best,
> 
> 		Ph.
> 
> 
> > On Friday, 13 February, 2015 07:02:32 Philipp K. Janert wrote:
> > > 
> > > [snip]
> > > 
> > > > 
> > > > Well what did you expect?
> > > 
> > > I do expect that gnuplot cleans up its own
> > > messes. It is not acceptable to put a program 
> > > (any program) in a totally wedged state through
> > > a series of totally legal commands.
> > 
> > Let's be clear.
> > Control-C is not a normal way to interact with a program.
> > It is an externally-triggered kill switch that in this case
> > you are using to bail out of your own programming error - an
> > infinite loop with no clean exit path.
> > 
> > Gnuplot or indeed any program would be perfectly entitled to
> > exit entirely in response.  
> > 
> > Instead, gnuplot tries to be a little nicer and at least get you back
> > to a command prompt without losing your entire session context.
> > It may not always succeed, in which case a second externally
> > triggered kill signal may complete the job.
> > 
> > If you have suggestions how to detect the infinite loop as
> > a syntax error, that would be helpful.
> > 
> > If you have thoughts about how to design a thread synchonization
> > mutex that is more robust in response to a user killing one of
> > the two threads, that might also be helpful.
> > 
> > Complaining that your foot hurts after you have chosen to 
> > shoot it multiple times in succession is not so helpful.
> > 
> > Here is a more correct version of the loop you intended to write:
> > 
> > spin.gp:
> >   t = 0
> >   done = 0
> >   bind all 'd' "done = 1"
> >   while( !done ) {
> >     t = t + 0.1
> >     splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
> >   }
> > 
> > Now a gnuplot command "load 'spin.gp'" will terminate
> > cleanly when you type a 'd' in the plot window.
> > 
> > Of course there is still the problem that your loop contains
> > no delay, so the display command stream it generates will
> > get longer and longer as it runs. That means the lag between
> > hitting 'd' and exhaustion of the accumulated command stream
> > will increase.  Adding "pause 0.01" to the loop would address this,
> > or perhaps the "load" command could be followed by some
> > cleanup to terminate the current display window and open 
> > a new one.  It depends on what you want.
> > 
> > 	Ethan
> 
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta