Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933127AbbLRQkE (ORCPT ); Fri, 18 Dec 2015 11:40:04 -0500 Received: from mail-pf0-f169.google.com ([209.85.192.169]:34666 "EHLO mail-pf0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932788AbbLRQkC (ORCPT ); Fri, 18 Dec 2015 11:40:02 -0500 Subject: Re: n_tty: Check the other end of pty pair before returning EAGAIN on a read() To: Marc Aurele La France References: <56699356.8040802@hurleysoftware.com> <566A13C2.7040803@hurleysoftware.com> <566AD5FC.6010407@hurleysoftware.com> Cc: Greg Kroah-Hartman , Jiri Slaby , linux-kernel@vger.kernel.org, Volth , Damien Miller From: Peter Hurley Message-ID: <567436DE.2020101@hurleysoftware.com> Date: Fri, 18 Dec 2015 08:39:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1598 Lines: 44 Hi Marc, 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? Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/