Will python ever have signalhandlers in threads?

[Tim Peters]

[Bengt Richter]
> 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.