Will python ever have signalhandlers in threads?

[Tim Peters]

[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).

Everything else is built on those, and CPython's thread implementation
is extremely portable-- and easy to port --as a result.

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).