mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michael Matz <matz@suse.de>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: NeilBrown <neilb@suse.de>,
	Nic Percival <Nic.Percival@microfocus.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.cz>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'
Date: Mon, 4 May 2015 14:24:13 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LSU.2.11.1505041409120.21748@wotan.suse.de> (raw)
In-Reply-To: <5543964C.9030606@hurleysoftware.com>

Hi,

On Fri, 1 May 2015, Peter Hurley wrote:

> I don't think this a real bug, in the sense that pty i/o is not 
> synchronous, in the same way that tty i/o is not synchronous.

Here's what I wrote internally about my speculations about this being a 
bug or not:

> > I also never hit it with pipes (remove the USEPTY define), also not on 
> > sle12, so it must be some change specific to the pty implementation.
> > 
> > Now, all of this is of course unspecified.  There are two asynchronous 
> > processes involved, and a buffered tube between them.  Just because 
> > one process filled one end of the tube (the breakpoint was hit) 
> > doesn't mean the contents have to appear at that instant at the other 
> > end.  So the change in behaviour in sle12 is not a genuine bug.  It 
> > _might_ be an unintented change, though, that's why kernel people 
> > should comment on this.  If there are no terribly good reasons for 
> > this change I'd consider it a quality-of-implementation regression in 
> > sle12.

So, I'd accept this being declared a non-bug, but it is certainly a change 
in behaviour that's visible for our debugger team.

> However, that said, if this is a regression (regression as in "it broke 
> something that used to work", not regression as in "this new thing I'm 
> writing doesn't behave the way I want it to" :) )
> 
> Help me understand the use-case here: are you using pty i/o to debug the 
> debugger?

Nic is working on the Cobol debugger, but I think this pty i/o is rather a 
part of the normal interaction between a debugged Cobol process and the 
debugger; that's just a theory, Nic is authorative here.  But this change 
in behaviour _did_ result in real testsuite regressions, so it's not 
something that he wanted to write from scratch.

(FWIW: I do think it's a better QoI factor if something returns data from 
a tube if we can know via side channels (break points) that something must 
have been written locally to the other end of the tube, if that can be 
ensured without too much other work)


Ciao,
Michael.

  reply	other threads:[~2015-05-04 12:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01  6:20 NeilBrown
2015-05-01 15:05 ` Peter Hurley
2015-05-04 12:24   ` Michael Matz [this message]
2015-05-04 16:32     ` Peter Hurley
2015-05-04 16:56       ` Michael Matz
2015-05-04 18:42         ` Peter Hurley
2015-05-05  8:20     ` Nic Percival
2015-05-05 11:18       ` Peter Hurley
2015-05-05 12:03         ` Nic Percival
2015-05-05 13:29           ` Peter Hurley
2015-05-05 13:34             ` Chris Purvis
2015-05-05 13:35               ` Peter Hurley
2015-05-05 13:37                 ` Chris Purvis
     [not found]                 ` <2F7A2F2395CAC340B30E7E8A7D95533DB672C022@NWB-EXCHANGE4.microfocus.com>
2015-05-05 17:39                   ` Chris Purvis
2015-05-05 22:59       ` [PATCH man-pages] pty.7: clarify asynchronous nature of PTY IO NeilBrown
2015-05-06 12:26         ` Michael Kerrisk (man-pages)
2015-05-06 13:36           ` Peter Hurley
2015-05-06 16:12             ` Michael Kerrisk (man-pages)

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.LSU.2.11.1505041409120.21748@wotan.suse.de \
    --to=matz@suse.de \
    --cc=Nic.Percival@microfocus.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®