All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Aurele La France <tsi@tuyoix.net>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	linux-kernel@vger.kernel.org, Volth <openssh@volth.com>,
	Damien Miller <djm@mindrot.org>
Subject: Re: n_tty: Check the other end of pty pair before returning EAGAIN on a read()
Date: Fri, 18 Dec 2015 10:23:41 -0700 (Mountain Standard Time)	[thread overview]
Message-ID: <alpine.WNT.2.00.1512180949380.3248@CLUIJ> (raw)
In-Reply-To: <567436DE.2020101@hurleysoftware.com>

On Fri, 18 Dec 2015, Peter Hurley wrote:
> On 12/18/2015 06:26 AM, Marc Aurele La France wrote:
>> On Fri, 11 Dec 2015, Peter Hurley wrote:
>>> On 12/11/2015 05:37 AM, Marc Aurele La France wrote:

>>>> I am not asking to read data before it has been produced.  I am puzzled
>>>> that despite knowing that the data exists, I can now be lied to when I
>>>> try to retrieve it, when I wasn't before.  We are talking about what is
>>>> essentially a two-way pipe, not some network or serial connection with
>>>> transmission delays userland has long experience in dealing with.

>>>> These previously internal additional delays, that are now exposed to
>>>> userland, are simply an implementation detail that userland did not,
>>>> and should not, need to worry about.

>>> Your mental model is that pseudo-terminals are a synchronous pipe, which
>>> is not true.

>>> But this argument is pointless because the regression needs to be fixed
>>> regardless of the merits.

>> Fair enough.

>> Anything new on this?

> It's on my todo list.

> While considering this issue further, I was curious what ssh does
> regarding the entire foreground process group and its output?

> If ssh only knows that the child has terminated, how does it wait
> for the rest of the foreground process group's output since those
> processes may not yet have received their SIGHUP/SIGCONT signals
> yet?

sshd cannot know about the termination of any process other than the
session leader because any of the session leader's children are
re-parented to init.  The idea is to, at minimum, collect any output the
session leader might have left behind.  Yes, this could entail also
collecting output from its children that might have squeaked in, but
that's gravy that can't be avoided.

This situation is much simpler on the *BSDs.  There, both ends of the
pty pair are, in effect, completely closed after disassociation of either
end, preventing (with EIO) any further output (but still allowing data
already collected to be read, after which an EIO occurs).  It's
unfortunate System V variants don't do this, but that's crying over spilt
milk.

Marc.

  reply	other threads:[~2015-12-18 17:24 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-09 21:06 n_tty: Check the other end of pty pair before returning EAGAIN on a read() Marc Aurele La France
2015-12-10 14:59 ` Peter Hurley
2015-12-10 22:48   ` Marc Aurele La France
2015-12-11  0:07     ` Peter Hurley
2015-12-11 13:37       ` Marc Aurele La France
2015-12-11 13:56         ` Peter Hurley
2015-12-18 14:26           ` Marc Aurele La France
2015-12-18 16:39             ` Peter Hurley
2015-12-18 17:23               ` Marc Aurele La France [this message]
2016-01-14 21:50                 ` Marc Aurele La France
2016-02-28 22:53 Brian Bloniarz
2016-02-28 23:02 Brian Bloniarz
2016-02-29  3:56 Brian Bloniarz
2016-03-01  4:30 ` Peter Hurley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.WNT.2.00.1512180949380.3248@CLUIJ \
    --to=tsi@tuyoix.net \
    --cc=djm@mindrot.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=openssh@volth.com \
    --cc=peter@hurleysoftware.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.