Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751408AbbEDQ4z (ORCPT ); Mon, 4 May 2015 12:56:55 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33841 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750969AbbEDQ4s (ORCPT ); Mon, 4 May 2015 12:56:48 -0400 Date: Mon, 4 May 2015 18:56:46 +0200 (CEST) From: Michael Matz To: Peter Hurley cc: NeilBrown , Nic Percival , Greg Kroah-Hartman , Jiri Slaby , linux-kernel@vger.kernel.org Subject: Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes' In-Reply-To: <55479F04.8010009@hurleysoftware.com> Message-ID: References: <20150501162040.05c0cb42@notabene.brown> <5543964C.9030606@hurleysoftware.com> <55479F04.8010009@hurleysoftware.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2224 Lines: 51 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. -- 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/