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. ;)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4