➜

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 sbt
Recipients Giovanni.Bajo, avian, bobbyi, gregory.p.smith, jcea, lesha, neologix, nirai, pitrou, sbt, sdaoden, vinay.sajip, vstinner
Date 2012-05-31.20:48:39
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1338497322.26.0.867275361492.issue6721@psf.upfronthosting.co.za>
In-reply-to
Content 
Attached is an updated version of Charles-François's reinit_locks.diff.

Changes:

* Handles RLock by assuming that if self->count != 0 when we acquire
  the lock, then the lock must have been reinitialized by PyThread_ReInitLocks().

* Applies existing fork tests for Lock to RLock.

* Fixes capitalization issues with PyThread_ReInitLocks()/PyThread_ReinitLocks().

* Defines PyThread_ReInitLocks() to be empty on non-pthread platforms.

Note that RLock._is_owned() is unreliable after a fork until RLock.acquire() has been called.

Also, no synchronization has been added for the list of locks.  Are PyThread_allocate_lock() and PyThread_free_lock() supposed to be safe to call while not holding the GIL?
History
Date User Action Args
2012-05-31 20:48:43sbtsetrecipients: + sbt, gregory.p.smith, vinay.sajip, jcea, pitrou, vstinner, nirai, bobbyi, neologix, Giovanni.Bajo, sdaoden, avian, lesha
2012-05-31 20:48:42sbtsetmessageid: <1338497322.26.0.867275361492.issue6721@psf.upfronthosting.co.za>
2012-05-31 20:48:41sbtlinkissue6721 messages
2012-05-31 20:48:39sbtcreate