Author avian
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, neologix, nirai, pitrou, sdaoden, vstinner
Date 2011-07-05.11:20:41
SpamBayes Score 2.22045e-16
Marked as misclassified No
Message-id <1309864842.21.0.629203178239.issue6721@psf.upfronthosting.co.za>
In-reply-to
Content
Except for multiprocessing, does anyone know of any other module in the standard library that uses fork() and threads at the same time? After some grepping through the source I couldn't find any other cases.

I'm still in favor of just deprecating using fork() on a multithreaded process (with appropriate warnings and documentation) and I'm prepared to work on a patch that would remove the need for helper threads in the multiprocessing module.

I gather that having atfork would be useful beyond attempting to solve the locking problem, so this doesn't mean I'm opposed to it. However debugging rare problems in multithreaded/multiprocess applications is such a frustrating task that I really don't like a solution that only works in the common case.

> In Python atfork() handlers will never run from signal handlers, and 
> if I understood correctly, Charles-François described a way to 
> "re-initialize" a Python lock safely under that assumption.

Just to clarify: it's not that POSIX atfork() handlers run from signal handlers. It's that after a fork in a multithreaded process POSIX only guarantees calls to "safe" functions, which is the same set of functions as those that are safe to call from signal handlers. This fact does not change for Python's os.fork().
History
Date User Action Args
2011-07-05 11:20:42aviansetrecipients: + avian, gregory.p.smith, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden
2011-07-05 11:20:42aviansetmessageid: <1309864842.21.0.629203178239.issue6721@psf.upfronthosting.co.za>
2011-07-05 11:20:41avianlinkissue6721 messages
2011-07-05 11:20:41aviancreate