This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author yonas
Recipients abo, astrand, benjamin.peterson, christian.heimes, djc, dsagal, exarkun, flox, gjb1002, gregory.p.smith, grossetti, gvanrossum, kanaka, nnorwitz, oefe, r.david.murray, siemer, tom_culliton, yonas
Date 2010-03-08.15:02:28
SpamBayes Score 6.5349394e-07
Marked as misclassified No
Message-id <1268060555.9.0.970865521333.issue1731717@psf.upfronthosting.co.za>
In-reply-to
Content
http://groups.google.com/group/comp.lang.python/browse_thread/thread/9a853d0308c8e55a


"I'm also glad to see a test case that causes exactly the same error with or without the presence of a ‘daemon.DaemonContext’.

Further research shows that handling of ‘SIGCLD’ (or ‘SIGCLD’) is fairly
OS-specific, with “ignore it” or “handle it specifically” being correct
on different systems. I think Python's default handling of this signal
is already good (modulo bug #1731717 to be addressed in ‘subprocess’).

So I will apply a change similar to Joel Martin's suggestion, to default
to avoid touching the ‘SIGCLD’ signal at all, and with extra notes in
the documentation that anyone using child processes needs to be wary of
signal handling.

This causes the above test case to succeed; the output file contains:: 
=====
Child process via os.system.
Child process via 'subprocess.Popen'.
Parent daemon process.
Parent daemon process done.
====="

  -- By Ben Finney
History
Date User Action Args
2010-03-08 15:02:36yonassetrecipients: + yonas, gvanrossum, nnorwitz, abo, gregory.p.smith, astrand, siemer, exarkun, gjb1002, oefe, christian.heimes, dsagal, tom_culliton, benjamin.peterson, djc, grossetti, r.david.murray, flox, kanaka
2010-03-08 15:02:35yonassetmessageid: <1268060555.9.0.970865521333.issue1731717@psf.upfronthosting.co.za>
2010-03-08 15:02:34yonaslinkissue1731717 messages
2010-03-08 15:02:29yonascreate