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 rnk
Recipients gregory.p.smith, hobb0001, jyasskin, pitrou, rnk
Date 2010-07-10.15:47:42
SpamBayes Score 0.00014948986
Marked as misclassified No
Message-id <1278776867.58.0.64335416345.issue8844@psf.upfronthosting.co.za>
In-reply-to
Content
Here's a patch that makes Python-level lock acquisitions interruptible for py3k.  There are many users of the C-level lock API, most of whom are not set up to deal with lock acquisition failure.  I decided to make a new API function and leave the others alone.

If possible, I think this should go out with 3.2.

In that case, I was wondering if I should merge PyThread_acquire_lock_timed with my new PyThread_acquire_lock_timed_intr, since PyThread_acquire_lock_timed wasn't available in 3.1.  Although it did go out in 2.7, we don't promise C API compatibility with the 2.x series, so I don't think it matters.

I've tested this patch on Mac OS X and Linux.  The whole test suite passes on both, along with the test that I added to test_threadsignals.py.

I added a noop compatibility wrapper to thread_nt.h, but I haven't tested it or built it.  When I get around to testing/fixing the subprocess patch on Windows, I'll make sure this works and the test is skipped.
History
Date User Action Args
2010-07-10 15:47:47rnksetrecipients: + rnk, gregory.p.smith, pitrou, jyasskin, hobb0001
2010-07-10 15:47:47rnksetmessageid: <1278776867.58.0.64335416345.issue8844@psf.upfronthosting.co.za>
2010-07-10 15:47:46rnklinkissue8844 messages
2010-07-10 15:47:45rnkcreate