The problem here is the way python handles unix signals asynchronously.
It just sets a flag in a dummy SIGCHLD handler, then waits for a bit of
python code to execute, at which point it will call the python SIGCHLD
handler. This may be handled differently if python has been built with
threading enabled (I don't remember).
You can probably work around this by setting up an idle or timeout
function that will be called every so often, triggering the python SIGCHLD
handler.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
On Wed, 12 Jan 2000, Martin Preishuber wrote:
> Hi all,
>
> Got some question concerning fork and signal in gnome-python
> applications:
> is there anything special which should be considered ? I made some app
> which installs a sigchld handler and does some forking:
>
> def SigChldHandler(signal_number, stack_frame):
> signal.signal(signal.SIGCHLD, SigChldHandler)
> result = os.wait()
>
> class Application:
> def __init__(self):
> signal.signal(signal.SIGCHLD, SigChldHandler)
> def run(self, args):
> result = os.fork()
> if (result == 0):
> os.execv("/usr/bin/env", ["/usr/bin/env", command])
>
> so the problem with that code is, that the sigchldhandler is
> executed when the next program is started / forked ... that means
> that there are always some zombie processes around ... any
> idea someone ?
>
> Martin
>
> --
> Martin Preishuber - Student, ECLiPt Core Member, SysAdmin
> http://eclipt.uni-klu.ac.at,
> mailto:[EMAIL PROTECTED]
>
> Wernher von Braun settled for a V-2 when he coulda had a V-8.
> To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
>
To unsubscribe: echo "unsubscribe" | mail [EMAIL PROTECTED]
