On Fri, Nov 16, 2001 at 06:25:44PM +0100, Dieter Maurer wrote:
Paul Winkler writes:
This is weird. I can understand how one of the Zope threads might get stuck waiting for the never-ending external process; but why should Zope become completely unresponsive? Shouldn't the other threads keep responding? They should (and usually do). Maybe a problem in Python: forgets to release the Global Interpreter Lock for the system call you use to start your process....
And is there a way to set a timeout for an external process, such that zope can recover if it fails to return for too long? If you use "os.system", then I fear there is no safe way. For "os.popen" (or variants thereof), you might be able to use "select" (with a timeout) to check whether the partner closed the file descriptor. If so, you abandon the process (without closing the file, neither explicitly nor implicitly!, i.e. must go into a global variable, preferably a list.). Of course, you will leak file descriptors in this case.
Thanks for the tip. I'm forwarding to Ron Bickers, author of Photo (the product I'm using that calls the external process), to make sure he sees this. It uses os.popen but doesn't check for failure. Unfortunately I'm now starting to doubt my diagnosis... had a couple more freezes that seemed unrelated to calls to convert. I'll try to keep bigM logs of every freeze, keep a close watch on running processes to see when convert dies and see if that's actually related at all. There always seems to be a defunct convert hanging around when I get a freeze, but I'm not sure that's actually the cause. -- paul winkler home: http://www.slinkp.com music: http://www.reacharms.com calendars: http://www.calendargalaxy.com