Will python ever have signalhandlers in threads?

[Tim Peters]

...

[Antoon Pardon]
> Sure but that is not enough is it? The work for letting one thread
> raise an exception in an other thread is done.

Are you talking about the internal PyThreadState_SetAsyncExc gimmick? 
If so, that's got nothing to do with signals.  If that's all you want,
say so, and leave signals out of it.

As to whether the work is done, emphatically no, it isn't.  I hadn't
looked at its implementation before, so just did.  That uncovered a
critical bug "by eyeball", which may delay the release of Python 2.4. 
Happy now <wink>?

Seriously, that's just an error in the C coding.  The work for a
Python-level feature hasn't even begun.  I'd guess it's about 5% of
the way there (believe it or not, writing C code is typically the
least time-consuming part of any language feature).

If you want to do that, fine.  Then because this functionality is
controversial, it needs a PEP.  That isn't "punishment", it's that
controversial decisions need a record of design rationale, and PEPs
are Python's way of making such records.  The Python-level API also
needs design and debate.  For example, the C-level API takes a thread
ID as argument, but that's a poor fit with threading.py's higher-level
view of threads.  In this case it probably needs a higher-level API. 
The C-level API also a bizarre gimmick where you're supposed to do an
obscure dance if the function returns a value greater than 1.  Offhand
I have no idea what that's all about, but it's clearly unacceptable
for a Python-level function (maybe some good news:  I suspect that
when the critical bug just found is fixed, that fix will automatically
stop the indeterminism driving the need for the goofy API dance). 
Thought also needs to be given to whether other implementations of
Python *can* supply this gimmick.  It's unclear to me.  The CPython
implementation of it is very simple, but relies in all respects on
implementation details unique to CPython (primarily the GIL, and that
there's an exhaustive linked list of thread states to crawl over).  A
new Python-level function also needs documentation, and a good test
suite.  The C-level API here isn't tested at all, which isn't good.

> But it still didn't get really in the language.

Of course it wasn't.  As above, this isn't anywhere yet near being a
language-level feature.  To judge from Guido's checkin comment, he was
also reluctant to add it even at the C level, which may (or may not)
be another battle.  FWIW, it's fine by me if this got exposed at the
Python level.  People will certainly get themselves in trouble by
using it, but the CPython implementation of this is so toothless I
don't think they'll be able to screw up internal states of the
platform C library by, e.g., leaving *its* synch gimmicks in
ill-defined states when they provoke a Python thread "externally" into
async surprises.

> All that was provided was the C interface and people who want to use
> it must provide the python interface themselves.

Yes.  And looking at the history, the C interface was in fact all that
was asked for at the time.

...

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

That's their call.  Beyond noting that few things are achieved by
those who give up easily, "that's life".

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

I'm confused now.  Up until this point, it appeared that "this", in
this message, was talking about the lack of access to
PyThreadState_SetAsyncExc from the Python level.  If so, that's got
nothing to do with signals, at least not in CPython.  The
implementation doesn't use signals, and is 100% portable exactly the
way it is.  And it's very simple.  Nobody can object to *this*
function on porting or maintenance-burden grounds.  They may object to
it on other grounds.

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

Read the code?  As I said before, I pay no attention to the signal
module, and the only way I could answer these questions is by studying
the code too.  Maybe someone else here already knows, and will chip
in.