Will python ever have signalhandlers in threads?

[Antoon Pardon]

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

Sure but that is not enough is it? The work for letting one thread
raise an exception in an other thread is done. But it still didn't
get really in the language. All that was provided was the C interface
and people who want to use it must provide the python interface
themselves.

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

I understand, but that also means one can't expect short term
contributors to put time in this, because they are likely to
see their time invested in this, going to waste.


Now I may invest some time in this anyway, purely for my own
interest. The question I have is, will I just have to fight
the normal signal behaviour or do I have to fight python as
well. To be more specific, the documentation of the signal
module states the following.

   ... only the main thread can set a new signal handler, and the main
   thread will be the only one to receive signals (this is enforced by
   the Python signal module, even if the underlying thread implementa-
   tion supports sending signals to individual threads).


The question I have is the following. That the main thread is the only
one to receive signals, is that purely implemented in the signal module
or is there some interpreter magic that supports this, which can
cause problems for an alternative signal module.


-- 
Antoon Pardon