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 pitrou
Recipients bobbyi, gregory.p.smith, neologix, pitrou, vstinner
Date 2011-05-04.17:53:47
SpamBayes Score 4.36225e-08
Marked as misclassified No
Message-id <1304531621.3568.11.camel@localhost.localdomain>
In-reply-to <>
> - what's current_thread_id ? If it's thread_get_ident (pthread_self),
> since TID is not guaranteed to be inherited across fork, this won't
> work

Ouch, then the approach I'm proposing is probably doomed.

> And it's true with every lock in the library code: they're only held
> in short critical sections (typically acquired when entering a
> function and released when leaving), and since it's not the threads
> inside those libraries that fork, all those locks can simply be
> reinitialized on fork, without having the reacquire them.

Well, this means indeed that *some* locks can be handled, but not all of
them and not automatically, right?
Also, how would you propose they be dealt with in practice? How do they
get registered, and how does the reinitialization happen?

(do note that library code can call arbitrary third-party code, by the
way: for example through encodings in the text I/O layer)
Date User Action Args
2011-05-04 17:53:48pitrousetrecipients: + pitrou, gregory.p.smith, vstinner, bobbyi, neologix
2011-05-04 17:53:47pitroulinkissue6721 messages
2011-05-04 17:53:47pitroucreate