> I agree that the problem lies in how Twisted deals with signal handling. > However, this has been a known problem with Twisted for a very long > time. Unfortunately, it doe not look like fixing it is much of a > priority. The usual response is that you should do things the Twisted > way and use their API to spawn a process. The problem comes for projects > like iPython that, ideally, shouldn't be exposing any of Twisted at all. > Perhaps you might have more traction with the Twisted folks, given that > you have a well known project that would benefit from fixing this bug. > As I understand it, the solution is to write a simple C extension module > that fixes signal handling - just no one has done it yet. I think your assessment is correct. When you use Twisted you have to buy into the entire universe. That is problematic and we may end up moving away from twisted. > I should also point out, that these problems don't exist if the calls to > subprocess occur in a separate thread spawned by deferToThread. I > haven't had time to look at the source, but how hard would it be to > setup the engines so that remote calls are run using deferToThread? I don't see how deferToThread helps as the signal handlers are process wide. Also, I don't think we can use deferToThread in our case for other reasons. Cheers, Brian > Regards, > Justin > > > On Feb 4, 2010, at 6:37 PM, Brian Granger wrote: > >> Yes, my feeling is that subprocess won't work reliably in any twisted >> using process as it installs its own signal handlers.  I will look >> into this though. >> >> Cheers, >> >> Brian >> >> On Thu, Feb 4, 2010 at 6:28 PM, Justin MacCallum >>