From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756745AbcANVuW (ORCPT ); Thu, 14 Jan 2016 16:50:22 -0500 Received: from smtp-out-so.shaw.ca ([64.59.136.139]:46864 "EHLO smtp-out-so.shaw.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756723AbcANVuT (ORCPT ); Thu, 14 Jan 2016 16:50:19 -0500 X-Authority-Analysis: v=2.1 cv=He60Nnw8 c=1 sm=1 tr=0 a=qZxK3cM5tHtOUZVZkOzy1Q==:117 a=qZxK3cM5tHtOUZVZkOzy1Q==:17 a=3I1X_3ewAAAA:8 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=0G0ks0WldRRLcbcrEGMA:9 a=CjuIK1q_8ugA:10 Date: Thu, 14 Jan 2016 14:50:09 -0700 (Mountain Standard Time) From: Marc Aurele La France To: Peter Hurley cc: Greg Kroah-Hartman , Jiri Slaby , linux-kernel@vger.kernel.org, Volth , Damien Miller Subject: Re: n_tty: Check the other end of pty pair before returning EAGAIN on a read() In-Reply-To: Message-ID: References: <56699356.8040802@hurleysoftware.com> <566A13C2.7040803@hurleysoftware.com> <566AD5FC.6010407@hurleysoftware.com> <567436DE.2020101@hurleysoftware.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-CMAE-Envelope: MS4wfLrasjNfFXItoMwH047Ya6KmYHgu3xZwpfNOiyVavvZHRDHaQnbcsOPce8kYyQW4IYTo4LgS5w8OmVoJ+9Sz7Szmx0Iv2jWVpqUp5qffB/TW408B8ZdY Vfw8mq0IdOImgfZmBG6zo8hfUvsHvp3FMu2q/D1cG+BDRj6kqcNKcixjR0v5eHA5KT5eh8ZrNE1XWD28o6toI2aJNo6Ypz2tglGdJVkSVHsyOXSfI44r7RK+ 1RPhI38FsewBaADu+zbGzBhrpG6/TcDvyhCTuARQnFkkrZjrtxjV7bi4GyBWaeCNVb+jX6kiqo6mu1ZWSbhxbAl1R0loCn0gZdBMzoYtUaw= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 18 Dec 2015, Marc Aurele La France wrote: > 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. Anything more on this? Thanks. Marc.