On 11/05/2015 01:35 PM, Pavel Labath wrote: > On 5 November 2015 at 05:25, Peter Hurley <[email protected]> wrote: >> On 11/04/2015 02:43 PM, Oleg Nesterov wrote: >>> Oh, I don't think "Automagically if ptrace" makes any sense... What makes >>> ptrace special? Afaics nothing. >>> >>> We can modify this test-case to use signals/futexes/whatever to let the >>> the parent know that the child has already done write(writefd), and it can >>> "fail" the same way. >> >> True. >> >> Also, new patches in mainline head make this _much_ less likely >> by scheduling the input processing kworker on the unbound wq (which means >> the kworker can start immediately on another cpu rather than pinned to >> the cpu performing the slave write). >> >> After thinking more about this, this use-case seems trivially solvable >> by re-select()ing with a timeout prior to reporting mismatch output >> failure. >> >> Regards, >> Peter Hurley >> > > Thank you for the replies. > > I agree that this can be worked around on our side, but I wanted to > confirm whether this is expected behavior or a bug. Judging from your > answers, it seems this is working as intended. > > That said, it seems to me that this could be a generally useful > feature. For the test suite, I can insert a sleep (even a large one, > to be sure), but this seems like a sub-optimal solution for general > debugger operation. E.g., when we want to display all tracee output(*) > before we print out the debugger prompt, we don't know if the tracee > has written anything, and we would need to sleep always, just in case > it has done that.
My comment suggesting re-select()ing was aimed at the test suite only. For the debugger, I would always mixin new output from the target regardless of when it arrived. But feel free to ignore my unsolicited design advice :) > This is especially tricky for remote debugging, as > the current gdb-remote protocol does not allow sending stdio after the > stop notification. Hmm, I could swear I've seen gdb scrolling away with new output while stopped. > So, I actually quite like the fsync() idea, but I > don't know if this is something that would be generally accepted (?). Let me think more on this; maybe I can come up with a way to trip it within an existing method. > (*) To avoid mixing output we don't have the tracee share the same > terminal with the debugger, but we create a new one, and do the > forwarding ourselves. Aside from avoiding output mixing, this > facilitates IDE integration, remote debugging, etc. > > > A side question: When I replace the pty with a pipe, the data seems to > be delivered immediately. Is this something that is guaranteed, or > this happens to work only accidentally and could change in the future > (e.g. by moving the pipe processing to a kworker process or whatever)? I would think the existing pipe behavior is more or less guaranteed, since pipes are commonly used for process synchronization. Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
