On Mon, Nov 29, 2010 at 12:55 AM, sfeam (Ethan Merritt) <[email protected]> wrote: > Could someone please enlighten me on what defines the expected > behavior in this case? To me it does not seem like a bug at all. > > The behavior is not specific to the wxt terminal or to a remote > session. It is visible already on a local session. In fact, you > don't even need to kill the x11 window: > % cat hang.bug > plot x > pause -1 > print "back from pause" > > %gnuplot hang.bug > ==> kill x-window externally if you like (doesn't matter) > ==> do NOT hit <cr> in the original terminal session > > Now from another terminal inspect the gnuplot process, which is > still waiting for input from the original: > #0 0xffffe424 in __kernel_vsyscall () > #1 0xb6ad7201 in select () from /lib/i686/libc.so.6 > #2 0x0812ac4d in wxt_waitforinput () at wxterminal/wxt_gui.cpp:3098 > #3 0x08062570 in pause_command () at command.c:1202 > #4 0x080635b9 in command () at command.c:596 > #5 do_line () at command.c:378 > #6 0x0809ebd6 in load_file (fp=0x931b4e0, name=0x931b6f8 "hang.bug", > can_do_args= > false) at misc.c:284 > #7 0x080a6aaa in main (argc=2, argv=0xbfca6e68) at plot.c:619 > > > The thing is, the "pause -1" command is doing exactly what it is supposed to. > The process is waiting to receive a <cr> from the terminal session before > continuing. If you now break or otherwise lose your connection to that > terminal session, then gnuplot is left waiting for a <cr> that will never > come.
I see now > But is this a bug in gnuplot? Not really a feature > Why is it different from any other hung terminal session? Yes will close this bug, and document as a feature. > You get the same behaviour from any process that is backgrounded > while waiting for terminal input. Right? Right > > > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
