Will python ever have signalhandlers in threads?

[Antoon Pardon]

Op 2004-11-15, Tim Peters schreef <tim.peters at gmail.com>:
> [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).

I don't fault the current Queue implementation. I think your arguments
are very strong and I'm not arguing that the current Queue implementation
should be replaced by a dozen none portable system dependent
implementation. But by limiting the signal module as it is now you make
it that much harder for people on posix systems to come up for a
different implementation on those systems.

The problem I have with the current implementation is not so much one
of burden on the system but one of possible "starvation" of a thread.

Suppose we have a number of consumers on a Queue, some simply block and
others use timeouts. The current implementation disfavors those threads
with a timeout too much IMO, because the block threads ask for the
lock continuosly while the timeout threads only ask for the lock
periodically.

-- 
Antoon Pardon