Re: Question about Ctrl-C and less

From: mark(at)mark(dot)mielke(dot)cc
To: Kevin Brown <kevin(at)sysexperts(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Question about Ctrl-C and less
Date: 2005-10-23 01:47:01
Message-ID: 20051023014701.GA9766@mark.mielke.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 21, 2005 at 05:06:45PM -0700, Kevin Brown wrote:
> > 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.

I think you are looking at 'every other pipeline application that does
nothing', and treating them as role models. :-)

I'm completely writing off applications that don't handle SIGINT in some
way, as psql already does this, and wouldn't need *any* change to work
this way. Psql already works the way you are saying every other application
you know of does. So, I'm not seeing your point.

If psql is to change, it is because the current behaviour is impractical,
and not for any other reason. What is the practical behaviour?

I think there are other, better ways, to know that the pager is
dead. One is SIGPIPE/EPIPE. A write to the pipe to the pager will
error with EPIPE, and throw a SIGPIPE signal. The parent will also
be notified with SIGCHILD when the child exits. In this way, we
have two ways of knowing that the child is dead, without preventing
SIGINT from being handled fully by the child, in a pager such as
less, that defines SIGINT to mean something *different* than die
or abort reading the input stream.

The case that this would be a problem for me is - psql is outputting
pages and pages of data. The pipe buffer becomes full (8192 bytes on
Linux?), and psql blocks. The rest of the data is available, however,
it has not yet been transferred to less. The user does some operation
in less that might take some time, and then hits control-C. Less
continues, but under your scheme, is faced with a terminated input
stream. I'm not seeing why this is practical. I don't see the benefit
of this.

Other than the argument that other applications don't handle Control-C
at all, and you think this is compatible with their behaviour, do you
have any practical arguments for doing it this way? How is it working
better than it does today? Why won't we have the same situation of
less and psql both waiting for STDIN from the user exist after your
suggestion to make psql close off the input stream sooner?

I might just be really dense. But I want you to show me where I'm wrong
before I give in. :-)

Cheers,
mark

--
mark(at)mielke(dot)cc / markm(at)ncf(dot)ca / markm(at)nortel(dot)com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2005-10-23 02:16:23 8.1 Beta 4 Bundled ...
Previous Message Qingqing Zhou 2005-10-23 01:44:38 Re: [PATCHES] Win32 CHECK_FOR_INTERRUPTS() performance