On 6/10/05, Itamar Shtull-Trauring wrote:

Register the same SIGCHLD handler twisted does in the main thread, that should work (they need to be reentrancy-safe anyway so the fact it's called from a different thread is fine). Possibly a more general solution could be devised for this, anyone have suggestions?

Thanks. So this behavior is by design? Again, it DID work before; for the last year or so, I've been using this code in production on a few servers. Perhaps a note could be made in the docs that ProcessProtocol doesn't work in this case. This will make it pretty hard to integrate into other worlds. I'm not sure that I can over-ride the signal handling in Webware and register handlers. Other bits of python libraries might be the same way. I look forward to any "more general solution" that anyone can come up with! Would the "twisted way" would be to run the reactor in a different python process and talk to it via rpc? The problem, of course, is that the best way to do that on the client end of the rpc is twisted, too! Thanks again.

On Jun 11, 2005, at 11:08 AM, Matt Feifarek wrote:

So this behavior is by design? Again, it DID work before; for the last year or so, I've been using this code in production on a few servers.

Perhaps a note could be made in the docs that ProcessProtocol doesn't work in this case.

There is one. It logs "spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process." However, your example doesn't have logging setup, so you don't see that message.

This will make it pretty hard to integrate into other worlds. I'm not sure that I can over-ride the signal handling in Webware and register handlers. Other bits of python libraries might be the same way.

I look forward to any "more general solution" that anyone can come up with!

If you cannot override the signal handling, do something like: from twisted.internet import task task.LoopingCall(process.reapAllProcesses).start(1.0, now=False) That's less efficient but will work. I have a vague recollection that in old versions twisted used to do this by default but I might just be making that up. James

Thanks, all, for the suggestions. This is certainly enough to get me started.

You're right; I stand corrected. What it DOES say is this: ValueError: signal only works in main thread Somebody here in the list or maybe on #twisted told me about the installSignalhandlers, I guess I must have conflated the two directives. It's been so long that I don't remember. As I said, I'm using this on 3 servers right now to serve thousands of image requests and convert them on the fly if necessary. Oh well. Time to find a new way. Thanks very much for your help. On 6/11/05, Jp Calderone wrote:

...

I don't see how it's non-public. Twisted TELLS you to use it if you run the reactor in a thread. That doesn't seem too secret to me.

Where does it do that?

James Y Knight wrote:

On Jun 13, 2005, at 11:40 PM, Matt Feifarek wrote:

I'd suggest continuing to do it the way you are currently. While installSignalHandlers may be undocumented, it's not just going to disappear overnight. If you use that parameter and task.LoopingCall(process.reapAllProcesses).start(1.0, now=False) then I'd say you're on fairly safe ground for the immediate future.

Overall we do a good job of keeping backwards compatibility even for APIs that may not be completely official, so it's unlikely to just up and disappear.

Perhaps a better way to handle this would be to create an official API to handle this problem, then distribute it as an external Python file you can include, which will have some forward-compatibility code put into it when newer versions of Twisted come out. I don't like the "let's never change anything because someone might be using it somewhere" approach that we've been taking. When we're making minor changes it's good but over time (especially given the sprawling nature of Twisted and the lack of any documentation on the state of its entirety) means tha we leave chunks of deprecated or semi-deprecated APIs around forever.

From an old thread[1]:

On Sat, 2005-06-11 at 11:35 -0400, Jp Calderone wrote:

On Sat, 11 Jun 2005 11:08:12 -0400, Matt Feifarek wrote:

...

On 6/10/05, Itamar Shtull-Trauring wrote:

...

Register the same SIGCHLD handler twisted does in the main thread, that should work (they need to be reentrancy-safe anyway so the fact it's called from a different thread is fine). Possibly a more general solution could be devised for this, anyone have suggestions?

Thanks.

So this behavior is by design? Again, it DID work before; for the last year or so, I've been using this code in production on a few servers.

Yep, and always has been. If it ever worked, it was by accident (I really don't see how it could have, though, so I can't begin to guess what might have changed to stop it).

...

Perhaps a note could be made in the docs that ProcessProtocol doesn't work in this case.

This will make it pretty hard to integrate into other worlds. I'm not sure that I can over-ride the signal handling in Webware and register handlers. Other bits of python libraries might be the same way.

I look forward to any "more general solution" that anyone can come up with!

Here's one:

def reapChildren(): from twisted.internet import reactor, task t = task.LoopingCall(reactor._handleSigchld, None, None) return t.start(5)

Of course, it uses a non-public method of reactor (but installSignalHandlers is a non-public argument to reactor.run(), so you're already treading on thin ice :)

I'm trying to diagnose an intermittent pausing problem on Win32, and t.i.process is unavailable on that platform, which reapChildren() relies on. Is there no need for this approach when launching the reactor with installSignalHandlers=0 on Windows? Steve [1]http://twistedmatrix.com/pipermail/twisted-python/2005-June/010692.html

On Sat, 2007-02-03 at 09:18 -0500, Itamar Shtull-Trauring wrote:

On Sat, 2007-02-03 at 01:27 -0800, Steve Freitas wrote:

...

I'm trying to diagnose an intermittent pausing problem on Win32, and t.i.process is unavailable on that platform, which reapChildren() relies on. Is there no need for this approach when launching the reactor with installSignalHandlers=0 on Windows?

No, SIGCHLD is a Unix thing.

Ok, thanks. Steve