Will python ever have signalhandlers in threads?
tim.peters at gmail.com
Tue Nov 16 03:52:41 CET 2004
> Would it be a big deal to give the acquire method an optional
> timeout=floating_seconds keyword arg, and have e.g. thread_nt.h use
> the timeout parameter in WaitForSingleObject? This could ripple up
> to Condition.aquire etc. and provide improved waiting over polling.
> (Of course, there's probably a number of polling processes going on
> all the time in the average windows session, but why add ;-)
> Do you think just a lock timeout would make it significantly harder?
> So what do you think about a lock timeout. Just that would let you
> build efficient terminatable substitutes for sleep and other timing things.
I rarely use timeouts, and, in the cases I do, haven't seen a
measurable burden due to the current wake-up-20-times-a-second
approach. So I have no motivation to change anything here.
Someone who does would have to go thru Python's 11 platform-specific
thread wrappers (these are C files in the Python/ directory, with
names of the form thread_PLATFORM.h), and figure out how to do it for
all of them -- or successfully argue that Python should no longer
support threads on those platforms for which they don't know how to
add the new core lock functionality -- or successfully argue (this one
is closer to impossible than unlikely) that platforms are free to
ignore the timeout argument.
More information about the Python-list