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?


More information about the Libraries mailing list