Will python ever have signalhandlers in threads?

[Bengt Richter]

On Mon, 15 Nov 2004 10:56:15 -0500, Tim Peters <tim.peters at gmail.com> wrote:

>[Antoon Pardon]
>> ...
>> AFAIU the Queue module doesn't block on a full/empty queue when
>> a timeout is specified but goes in a loop sleeping and periodically
>> checking whether place/items are available. With signals that
>> can be sent to a thread the queue could just set an alarm and
>> then block as if no timeout value was set and either unblock
>> when place/items are available or get signalled when the timeout
>> period is over.
>
>The only things CPython requires of the *platform* thread implementation are:
>
>1. A way to start a new thread, and obtain a unique C long "identifier"
>   for it.
>
>2. Enough gimmicks to build a lock object with Python's core
>   threading.Lock semantics (non-rentrant; any thread T can release
>   a lock in the acquired state, regardless of whether T acquired it).

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 ;-)
>
>Everything else is built on those, and CPython's thread implementation
>is extremely portable-- and easy to port --as a result.
>
Do you think just a lock timeout would make it significantly harder?

>Nothing in CPython requires that platform threads support directing a
>signal to a thread, neither that the platform C library support an
>alarm() function, nor even that the platform have a SIGALRM signal.
>
>It's possible to build a better Queue implementation that runs only on
>POSIX systems, or only on Windows systems, or only on one of a dozen
>other less-popular target platforms.  The current implementation works
>fine on all of them, although is suboptimal compared to what could be
>done in platform-specific Queue implementations.
>
>For that matter, even something as simple as threading.RLock could be
>implemented in platform-specific ways that are more efficient than the
>current portable implementation (which builds RLock semantics on top
>of #2 above).
So what do you think about a lock timeout. Just that would let you build
efficient terminatable substitutes for sleep and other timing things.

Regards,
Bengt Richter