Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

[Ethan A M. <me...@uw...>]

On Saturday, 3 September 2022 13:04:11 PDT Dima Kogan wrote:
> Hans-Bernhard Bröker <HBB...@t-...> writes:
> 
> > Am 02.09.2022 um 02:22 schrieb Dima Kogan:
> >
> >> It feels like an odd thing to do to specifically mask out SIGTSTP,
> >> but I guess that's fine. Masking out SIGINT creates zombies, though,
> >
> > Well, the documented intent is to keep gnuplot_x11 from being killed
> > by Ctrl-C or Ctrl-Z typed into the console --- presumably the one its
> > parent gnuplot process was started from.
> 
> But you DO want it to die when the user hits C-c on the console!

Your expectations are unusual in this regard.
Ctrl-C is a normal way to return control to an interactive session.
For example it is documented as the recommended way to break out of a
long-running "fit" command.  It is safe to hit Ctrl-C in any gnuplot session.
The program will not exit and the graphics window will not close.

> Otherwise you get zombies. 

I suspect these are not zombies. Can you kill then with SIGTERM?
  killall gnuplot_x11 -SIGTERM

More likely they are hung waiting for piped input from a gnuplot
session that segfaulted.  That is not something that should be an
issue unless you have a more fundamental problem with the
gnuplot end of the pipe, and you can clean them up with 'killall'
if it bothers you to see them listed in a process table.

	Ethan


> There's some logic in there to die via a more
> "controlled" path or something, so most of the time the child
> gnuplot_x11 process does go away in response to a C-c, but sometimes it
> doesn't. I do see straggler gnuplot_x11 processes sometimes. And when
> debugging some updates to gnuplot_x11 I see them all the time.
> 
> 
> > It would be _very_ surprising to find out that this particular snippet
> > would have been as badly wrong as you claim it to be, after all this
> > time. X11 may be considered unimportant by some today, but that
> > definitely would have been no excuse of the majority of that time
> > frame.
> 
> I claim there's a bug, not that gnuplot_x11 is horribly, unusably
> broken. There are other gnuplot_x11 bugs that definitely exist that I
> can report too, but nobody has the cycles to work on them (including
> me), so that's not obviously useful.