Hello, > > I've submitted a patch (*) to add an optional timeout to locking > > operations (Lock.acquire() etc.). Since it's a pretty basic > > functionality, I would like to know if there was any good reason for > > not doing it. > > I always assumed it was because as a least-common-denominator set of > functionality, some platforms didn't have the necessary support. Guido's answer says so indeed. Now py3k only needs to support POSIX and Windows (and, provided Andrew MacIntyre maintains the port, OS/2), which both have standard support for waiting-with-timeout. > Providing the discussion on this ends up with the an implementation > being accepted, I'd absolutely love to see this then leveraged by > threading.Condition.wait() rather rather than the current > poll-with-timed-sleep approach. Agreed. The current patch (as proposed on http://bugs.python.org/issue7316) includes exactly that. Poll-with-timed-sleep is especially sub-optimal on laptops where short but frequent wakeups can cause a significant decrease in battery life. (the Linux community has been chasing this using powertop: http://www.lesswatts.org/projects/powertop/) Feel free to test or review if you're interested. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4