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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
