fixed processTranscript hang problem
The pipe's FDs got inherited by ssh and it did something that kept them open even once it exited. Probably involving passing them on to the ssh mux daemon. Set close on exec, and all is well. Kept Annex.Ssh not using processTranscript even though it no longer hangs when it does use it, just because processTranscript is overkill there. This commit was supported by the NSF-funded DataLad project.
This commit is contained in:
parent
d6700721c0
commit
d2af6baaeb
2 changed files with 20 additions and 6 deletions
|
@ -42,6 +42,8 @@ processTranscript'' cp input = do
|
|||
{- This implementation interleves stdout and stderr in exactly the order
|
||||
- the process writes them. -}
|
||||
(readf, writef) <- System.Posix.IO.createPipe
|
||||
System.Posix.IO.setFdOption readf System.Posix.IO.CloseOnExec True
|
||||
System.Posix.IO.setFdOption writef System.Posix.IO.CloseOnExec True
|
||||
readh <- System.Posix.IO.fdToHandle readf
|
||||
writeh <- System.Posix.IO.fdToHandle writef
|
||||
p@(_, _, _, pid) <- createProcess $ cp
|
||||
|
|
|
@ -41,14 +41,26 @@ code.
|
|||
> (Arguably there should be locking to prevent multiple threads doing
|
||||
> this, but the actual overhead of multiple threads doing it may be
|
||||
> smaller than the overhead of such added locking.)
|
||||
>
|
||||
> Converted makeconnection to not use processTranscript,
|
||||
> and that does seem to avoid the hang.
|
||||
>
|
||||
> Why is makeconnection's use of processTranscript hanging?
|
||||
> processTranscriot tries to read the process's output (ssh has none),
|
||||
> and waiting for the output to get read is for some reason hanging
|
||||
> forever, despite the ssh process becoming a zombie.
|
||||
> Converted makeconnection to not use processTranscript,
|
||||
> and that does seem to avoid the hang.
|
||||
> forever, despite the ssh process becoming a zombie. I actually
|
||||
> rewrote the part of processtranscript that reads the process's input,
|
||||
> to be a much simpler use of async, and that new implementation has the
|
||||
> same problem. It's hanging, not throwing an exception. Most puzzling!
|
||||
>
|
||||
> Hmm.. Perhaps the write handle is staying open even after ssh exits?
|
||||
> processTranscript sets up a pipe for the process to write to, and
|
||||
> the ssh process may inherit the FDs for that pipe (other than as stdout and
|
||||
> stderr). If the write handle
|
||||
> remains open, reading from it would block. Since the ssh mux server is
|
||||
> involved, and the handle might be passed to it or something, that seems
|
||||
> at least possible as the cause. The windows version of createProcess
|
||||
> does not use that pipe, and switching to use it does avoid the hang.
|
||||
> Yep! Setting the pipe's FDs to close on exec did avoid the hang.
|
||||
>
|
||||
> So, this bug is left open only because processTranscript hangs in situations
|
||||
> like this. No other uses of it involve concurrency, but we still need to
|
||||
> get to the bottom of its hang.. --[[Joey]]
|
||||
> [[done]] --[[Joey]]
|
||||
|
|
Loading…
Reference in a new issue