Re: Question about Ctrl-C and less - Mailing list pgsql-hackers

mark@mark.mielke.cc wrote:
> On Thu, Oct 20, 2005 at 03:42:10PM -0700, Kevin Brown wrote:
> > Martijn van Oosterhout wrote:
> > > You can't do a pclose in a signal handler, it's not one of the
> > > "reeentrant safe" functions and could lead to deadlocks. The signal
> > > manpage documents the ones you can use. Just set a flag. Setting the
> > > descriptor to NULL is worse because then we have check before every
> > > output function. fprintf(NULL, ...) will segfault on most
> > > architechtures I wager. 
> > Yeah, I was thinking that you'd do the check for the flag and invoke a
> > cleanup handler after the write() to the output file descriptor.  It's
> > not clear that you'd need to do the check anyplace else.  It's been a
> > while since I've messed with this stuff, but if I recall correctly,
> > the write() will return immediately after receipt of a signal, and
> > will indicate how much was actually written.  So receipt of a SIGINT
> > should wind up being handled in a reasonably timely fashion.
> 
> > Additionally the normal SIGINT signal handler (the one that gets
> > invoked when the pager is turned off) can be called from the cleanup
> > handler in order to maintain the proper semantics.
> 
> I disagree that psql should make *any* assumptions about what SIGINT
> means to the child process. Consider less again, and Control-C used
> to abort a search. You are suggesting that Control-C should not only
> abort the search, but should also cut off the input from less. Less
> won't die. Less will just see a terminated input stream. What has been
> gained from this? Is this intuitive behaviour?

It's behaviour that's consistent with every other pipeline application
set I've ever seen.

The only difference between those and this situation is that for a
standard pipeline set, SIGINT will kill all the processes in the
pipeline.  Less explicitly ignores (or traps) SIGINT, so the effect of
generating a SIGINT where less is at the end of the pipeline is to
kill everything that precedes it, and less will then show what results
it received.  And obviously, that implies that the pipeline gets
closed.

If psql does not close the pipeline right then and there, then its
behaviour will obviously be different from what the user likely
expects, based on other pipelined uses of less.  After all, if they
wanted to see the entire result set then they wouldn't have sent
SIGINT, would they?

> If the pager does die in response to SIGINT, the write() will fail with
> SIGPIPE. Completely clean, without any need for psql to pay attention
> to SIGINT.

We're not talking about the semantics of the pager, we're talking
about the semantics of psql.  You said it yourself: psql can't make
any assumptions about what SIGINT means to the child process.  So it
has to consider what to do if the child does *not* die in response to
SIGINT.  What are the proper semantics for psql + the child in that
situation?

Well, I think it's clear that having psql ignore SIGINT in that
situation is *not* correct, because it implies that whether or not
SIGINT causes processing to stop (as the user would expect) depends
entirely on the child.  More specifically, it would depend on the
child either dying or explicitly closing its stdin upon receipt of
SIGINT.

The bottom line is that, at least in my opinion, the semantics of
SIGINT as regards psql should be the same whether or not there's a
pager involved, with one crucial difference: if there's a pager
involved, psql should wait for it to terminate before showing the
prompt.  But otherwise, the semantics should be identical, because
they are what the user expects.

> I think the only reasonable behaviour is to ignore SIGINT within the
> parent, until the child exits. I don't see why other behaviours are
> even being considered. To me, it points at a misunderstanding of the
> problem.

Not at all.  When you send SIGINT to a process, you want that process
to stop doing whatever it's doing and return control to you.  That's
what it means, and that's what it's for.  If we ignore SIGINT then
obviously we will *not* be heeding the wishes of the user who sends
SIGINT, and that is not likely what the user expects.


-- 
Kevin Brown                          kevin@sysexperts.com