Will python ever have signalhandlers in threads?

[Tim Peters]

[Antoon Pardon, on thread gimmicks]
> Couldn't it be possible to have a general solution that works on
> any kind of box

Yes, because we have that now.

> and provide (or let interested parties provide) an implementation that
> is better suited for particular boxes?

For the most part, that hasn't happened.  Someone who cares enough
would need to volunteer (or fund) API redesign to make it feasible.

...

> Look, I understand perfectly. Use of signals is never my first choice.
> However there sometimes seem to be circumstances when signals
> are the lesser evil. My impression is also that the python people
> seem to have some obligation to help in debugging peoples
> programs. This is laudable in general but I also have the impression
> that this obligation puts limits on what they want to allow in the
> language.
> 
> If I hear people argueing about why some things are missing I get
> the impression something like the following argument line is followed
>
>     I don't want to be bothered by the mess that can originate from
>     ill use of such a feature, I don't want to look trough code
>     that doesn't work from someone who doesn't understand how to
>     use this feature properly. So we don't include the feature in
>     the language (or only put the C-function in).
>
> And that is something I find regretable.

Look at the other ("supply") end of the development process:  nothing
can possibly go into Python until someone wants it enough to volunteer
to do all the work, or enough to pay someone else to do all the work. 
The former is most common, but the latter has happened too.

Now in this case, who cares?  Enough to actually do it, that is?  As I
said before, my experience with signals was mostly negative, so
there's no chance I'm going to volunteer my time to advance "a
feature" I dislike and won't use.  Someone *could* pay me to work on
it, and I'd do that if I couldn't find a less objectionable way to get
fed <wink>.

Nothing gets in just because someone asks for it, or even just because
everyone asks for it.  Someone has to do the work.

Who's that someone in this case?

The only currently active contributor I can think of who cares about
signals enough to actually work on them is Michael Hudson, but his
interest seems limited to keeping the interactions been Python's GNU
readline wrapper and signals working across incompatible details of
signal semantics on Unixish boxes.  It's possible I'm wrong, and he'd
really love to work much more on signals, but feels inhibited by
Guido's well-known dislike of the beasts.

That's not what I'd bet on, though.  Historically, even the limited
signal support Python supplies has been an endless maintenance burden,
hard to compare with anything else on the low end of the
bang-for-the-buck scale; maybe with the endless battle to try to
support threads *at all* across a gazillion incompatible flavors of
HP-UX.

And because it's sitting in the volunteer-development ghetto, you bet
it would be a hard sell to try to introduce "more of the same". 
Initial volunteers often vanish, leaving their maintenance problems to
others.  I expect (and you do too, so don't act surprised <wink>) that
"new signal features" could get vetoed for that reason alone -- the
simple observation that no current long-time contributor pushes in
this direction means there's no reason to presume that long-time
support for new signal gimmicks would exist.

...

> Sure but simple Locks can't have a timeout. So if you only need locks
> with a timeout then you use Queues that can only have 1 element.
> I agree that having multiple thread accessing the same queue some
> with a timeout and others not, is strange. But I think it is less
> strange if you have multiple threads accessing the same lock, some
> with timeouts and others not.

In this case I expect it's 1000x more common to use a
threading.Condition than a Queue.Queue.  Condition.wait() supports a
timeout, and a condvar is a much more obvious model for mutual
exclusion with a timeout than is a 1-element Queue.

It's still (of course) the case that Condition.wait() with a timeout
uses the same sleep/check/loop approach in the current implementation.
 BTW, the Queue implementation in 2.4 doesn't have any timeout code of
its own; instead its timeout behavior is supplied by
Condition.wait()'s.  From a lower-level view, confining timeout
*implementation* to Condition.wait() is a good idea for pthreads
systems, where pthread_cond_timedwait() could be used pretty much
directly.