Zombie sh instances in System.Process
Sterling Clover
s.clover at gmail.com
Sun Feb 3 22:19:29 EST 2008
I was initially building strictify on top of
System.Process.runInteractiveCommand. However, I soon ran into a
fairly significant issue with the interface. Even once the process I
was calling had terminated, and I had explicitly closed all its
buffers, a zombie sh process was left around from it. As I was
spawning, sequentially, lots of processes, this soon consumed too
many resources and errored out. As I understand it, the sh process is
used for redirection (in fact, I ended up implementing a variant of
the same thing on top of System.Posix.Process eventually) and needs
to stick around for a while, so that issues with lazyIO don't prevent
the handles provided by command from terminating before we've read
everything we want to. However, at the same time, it seems like a
terrible idea to have these buffers stick around *forever*. I dug
into the haskell code, but didn't look at the foreign C calls it was
based on.
This behavior seems pretty clearly broken to me, but I'm not sure
what the exact solution should be. Possibly providing an explicit API
method to shut the process down? Possibly blocking on polling its
buffers and terminating the sh instance once all three buffers are
explicitly or implicitly closed?
--Sterl.
More information about the Libraries
mailing list