Messages in this thread | | | Subject | Re: ptrace and pseudoterminals | From | Peter Hurley <> | Date | Thu, 5 Nov 2015 15:29:43 -0500 |
| |
On 11/05/2015 01:35 PM, Pavel Labath wrote: > On 5 November 2015 at 05:25, Peter Hurley <peter@hurleysoftware.com> 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
| |