Re: [PATCH bisected regression] input_available_p() sometimes says 'no' when it should say 'yes'

[Peter Hurley <peter@hurleysoftware.com>]

On 05/04/2015 08:24 AM, Michael Matz wrote:
> 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.

I'd like to understand why the debugger cares about when pty i/o shows up
and why there is a testsuite to check for that.

Does the debuggee know about the debugger, or is the pty i/o just stdout/stderr?

This doesn't seem stable in the face of multiple threads of execution in
the debuggee (or grandchild processes); IOW, pty slave writes from the
debuggee may continue from other non-TRACEME threads. Presumably that i/o
isn't being read either.

> (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)

Well, if the debugger simply continues to monitor the pty master, the i/o
will arrive.

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

Regards,
Peter Hurley