Will python ever have signalhandlers in threads?
tim.peters at gmail.com
Mon Nov 15 16:56:15 CET 2004
> 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"
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).
More information about the Python-list