Message109883
| 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:47 | rnk | set | recipients:
+ rnk, gregory.p.smith, pitrou, jyasskin, hobb0001 |
| 2010年07月10日 15:47:47 | rnk | set | messageid: <1278776867.58.0.64335416345.issue8844@psf.upfronthosting.co.za> |
| 2010年07月10日 15:47:46 | rnk | link | issue8844 messages |
| 2010年07月10日 15:47:45 | rnk | create |
|