Issue 3155: Python should expose a pthread_cond_timedwait API for threading (original) (raw)
Issue3155
Created on 2008-06-20 23:23 by gregory.p.smith, last changed 2022-04-11 14:56 by admin. This issue is now closed.
| Messages (3) | ||
|---|---|---|
| msg68484 - (view) | Author: Gregory P. Smith (gregory.p.smith) *  |
Date: 2008-06-20 23:23 |
| Currently the threading module has loops in it such as threading.Condition.wait's loop that attempts to acquire a lock in non-blocking mode and if it fails, sleeps for a while and trys again. (with exponential backoff of sleep time from 500us to 50ms in the current implementation). This is inefficient. Perhaps pthread_cond_timedwait does the same thing internally in some implementations but even if so, it will do it a lot more efficiently than doing it in python. We should expose a PyThread_acquire_lock API that accepts a timeout and uses pthread_cond_timedwait (or the equivalent on other OSes) when available. caveats? This may alter behavior with regards to KeyboardInterrupt exceptions coming in being processed or not depending on the particular OS timedwait implementation. | ||
| msg109299 - (view) | Author: Mark Lawrence (BreamoreBoy) * | Date: 2010-07-05 05:31 |
| Is anybody with knowledge of the threading module likely to pick this one up? | ||
| msg109578 - (view) | Author: Antoine Pitrou (pitrou) * |
Date: 2010-07-08 19:35 |
| I hadn't seen this issue existed. This has been done in r80071 (see issue #7316). |
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2022-04-11 14:56:35 | admin | set | github: 47405 |
| 2010-07-08 19:35:07 | pitrou | set | status: open -> closednosy: + pitroumessages: + superseder: Add a timeout functionality to common locking operationsresolution: out of date |
| 2010-07-05 05:31:05 | BreamoreBoy | set | nosy: + BreamoreBoymessages: + |
| 2008-06-21 17:16:16 | Rhamphoryncus | set | nosy: + Rhamphoryncus |
| 2008-06-20 23:23:26 | gregory.p.smith | create |