[Python-Dev] pthreads, fork, import, and execvp (original) (raw)
Gregory P. Smith greg at krypto.org
Wed Sep 9 20:38:53 CEST 2009
- Previous message: [Python-Dev] pthreads, fork, import, and execvp
- Next message: [Python-Dev] FWD: Front Runner Program
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 pthreadatfork 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. ;)
- Previous message: [Python-Dev] pthreads, fork, import, and execvp
- Next message: [Python-Dev] FWD: Front Runner Program
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]