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 18:56:46 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LSU.2.11.1505041833480.21748@wotan.suse.de> (raw)
In-Reply-To: <55479F04.8010009@hurleysoftware.com>

Hi,

On Mon, 4 May 2015, Peter Hurley wrote:

> I think it would be a shame if ptrace() usage forced a whole class of 
> i/o to be synchronous.

I think Neils patch doesn't do that, does it?  If it has an indication 
that in fact some data must be there but isn't it pulls it, otherwise it's 
the same as after your patch/current state?

(Leaving the debugger question to Nic; but I guess it's similar interface 
like gdb.  Once you come back into the debugger (breakpoint hit) it looks 
once for input on the tubes of the debuggee and then enters a prompt; it 
doesn't continue looking for input until you continue the debuggee (1).  
ptys would be used because it's Cobol, the programs contain data entry 
masks presumably needing a real tty, not just pipes.  That usecase would 
be broken now; the tty provided by the debugger doesn't reflect the real 
screen that the debuggee actually generated before the breakpoint.  Note 
how pipes in my test program _are_ synchronuous in this sense, just ptys 
aren't.)


Ciao,
Michael.

(1) And in a single threaded debugger (no matter if the debuggee is 
multithreaded) it would be awkward to implement.  After read returns 0 
you'd again call poll, which indicates data is there, and read again.  
You repeat that until $SOMEWHEN.  But when is it enough?  Two loops, 10, 
1000?  To not sit in a tight loop you'd also add some nanosleeps, but that 
would add unnecessary lags.

Basically, whenever poll indicates that read won't block then it should 
also return some data, not 0, if at all reasonably implementable; i.e. 
some progress should be guaranteed.  I realize that this isn't always the 
case, but here it is.  In code, this loop:

  while (poll ([fd, POLLIN], 0) == 1)
    // So, read won't block, yippie
    if (read (fd, ...) == 0)
      continue;

shouldn't become a tight loop, without the read making progress but the 
kernel continuously stating "yep, there's data available", until some 
random point in the future.

  reply	other threads:[~2015-05-04 16:56 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
2015-05-04 16:32     ` Peter Hurley
2015-05-04 16:56       ` Michael Matz [this message]
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.1505041833480.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®