Home Original page

[Python-Dev] pthreads, fork, import, and execvp

Gregory P. Smith greg at krypto.org
Wed Sep 9 20:38:53 CEST 2009 
On Wed, Sep 9, 2009 at 11:36 AM, Thomas Wouters<thomas at python.org> wrote:
>
> On Wed, Sep 9, 2009 at 20:19, Gregory P. Smith <greg at krypto.org> wrote:
>>
>> Take a look at http://code.google.com/p/python-atfork/ which I created
>> to address the general fork+threading with locks held causing
>> deadlocks issue with many standard library modules.  Currently it only
>> patches the logging module but I intend to support others.  I want to
>> get an atfork mechanism into 2.7/3.2 along with every lock in the
>> standard library making proper use of it.
>>
>> See also http://bugs.python.org/issue6721
>>
>> I make no attempt to deal with C-level locks, only those acquired from
>> python.  It doesn't use pthread_atfork but instead models its behavior
>> after that and wraps os.fork and os.forkpty so that they call the
>> registered atfork methods as appropriate.
>
> Well, sure, the *Python code* side of the problem is fixable, thanks to
> Python being so awesome ;-P I'm strictly thinking of applications embedding
> Python (or even extending it and calling into code that doesn't consider
> Python.) Your python-atfork project looks like a terribly good idea, but it
> won't fix the embedding/extending issues (nor is it intended to, right?)

yeah I decided to only fix what could obviously be fixed and was
causing me pain at the moment. ;)
More information about the Python-Dev mailing list