Menu
▾
▴
gnuplot-beta
|
From: Philipp K. J. <ja...@ie...> - 2015-02-13 01:08:19
|
I seem to be encountering a problem when running
splot in a loop.
Assume this is in a file called "script.gp":
t = 0
while( 1 ) {
t = t + 0.1
splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
}
Then
load "script.gp"
runs fine and can be stopped w/ Control-C.
Now, let's assume that I let it run for a few
seconds, then stop it, then "load" the script
again. After about 2 or 3 repetitions of this
cycle, gnuplot becomes unresponsive - sometimes
printing the following message:
wxt display server shutting down - no response
Gnuplot not exited using gp_exit(). Exit handlers may not work
correctly!
Sometimes not even that. It has to be killed
externally.
Is this known behavior? I have no idea how to
debug this. (The problem is not an overflow
of "t". I checked that.)
Best,
Ph.
|
|
From: sfeam <sf...@us...> - 2015-02-13 06:24:47
|
On Thursday, 12 February 2015 05:08:09 PM Philipp K. Janert wrote:
>
> I seem to be encountering a problem when running
> splot in a loop.
>
> Assume this is in a file called "script.gp":
>
> t = 0
> while( 1 ) {
> t = t + 0.1
> splot [][][-1:1] cos(sqrt(x**2+y**2) - t)
> }
>
> Then
> load "script.gp"
> runs fine and can be stopped w/ Control-C.
>
> Now, let's assume that I let it run for a few
> seconds, then stop it, then "load" the script
> again. After about 2 or 3 repetitions of this
> cycle, gnuplot becomes unresponsive - sometimes
> printing the following message:
>
> wxt display server shutting down - no response
> Gnuplot not exited using gp_exit(). Exit handlers may not work
> correctly!
>
> Sometimes not even that. It has to be killed externally.
I suspect it would work to hit ctrl-C twice in quick
succession. There is an extra check for pretty much
exactly this case.
> Is this known behavior?
Well what did you expect?
You put the program in an infinite loop sending messages
from one process (gnuplot main program) to another
(outboard wxt driver running in a separate thread)
with no delay in the loop.
So the communication channel between them is presumably
saturated. Then you kill one end with ^C, probably
truncating the last message sent. Is it any
wonder that the other end of the channel is left waiting for
completion of that last message, which never comes?
> I have no idea how to
> debug this. (The problem is not an overflow
> of "t". I checked that.)
I don't really see anything to debug.
Try ^C ^C.
If that doesn't work then open up gdb -p <pid>
using the pid of the hung process and type
"where" to find where it is stuck.
But I'll bet it's waiting for a poll() operation
on the communication channel which is now defunct.
Ethan
|
|
From: Philipp K. J. <ja...@ie...> - 2015-02-13 14:54:10
|
[snip] > > Sometimes not even that. It has to be killed externally. > > I suspect it would work to hit ctrl-C twice in quick > succession. There is an extra check for pretty much > exactly this case. Is this "double-Control-C" (which does work!) mentioned anywhere in the documentation? [snip] |
|
From: Philipp K. J. <ja...@ie...> - 2015-02-13 15:02:39
|
[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. [snip] |
|
From: Ethan A M. <sf...@us...> - 2015-02-13 20:56:11
|
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
|
|
From: Philipp K. J. <ja...@ie...> - 2015-02-13 21:37:47
|
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.
With such a warning in place, I think that's
perfectly acceptable behavior, and could have
been said in just so many words.
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? 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. Or is it a fact that any loop that
needs to respond to a user event MUST contain
pause? 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?
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
|
|
From: Ethan A M. <sf...@us...> - 2015-02-13 22:48:12
|
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 |
