Will python ever have signalhandlers in threads?

[Antoon Pardon]

I have had a look at the signal module and the example
and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

 

[Antoon Pardon]

I have had a look at the signal module and the example
and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

Well I guess that the lack of response means the anser is:

Not likely.


Pity!

 

[Fernando Perez]

Well I guess that the lack of response means the anser is:

Not likely.

Sorry that I don't have time to go through the code you mention, but recently
for ipython I had to deal with signal handling in threads. You can look in
IPython's Shell.py for the hacks I ended up using, if you care.

The gist of it is this function, which gets installed into a gtk/WX timer:

def runcode(self):
"""Execute a code object.

Multithreaded wrapper around IPython's runcode()."""

# lock thread-protected stuff
self.ready.acquire()

# Install sigint handler
signal.signal(signal.SIGINT, sigint_handler)

if self._kill:
print >>Term.cout, 'Closing threads...',
Term.cout.flush()
for tokill in self.on_kill:
tokill()
print >>Term.cout, 'Done.'

# Run pending code by calling parent class
if self.code_to_run is not None:
self.ready.notify()
self.parent_runcode(self.code_to_run)
# Flush out code object which has been run
self.code_to_run = None

# We're done with thread-protected variables
self.ready.release()
# This MUST return true for gtk threading to work
return True

As you see, I ended up installing the handler on *every* invocation of the
function, after taking a lock. I couldn't find how to assign the handler to
the thread, so this was my brute-force approach.

This is incredibly ugly, and there may be a better solution. But in this
particular case, the hack works and the penalty is not noticeable to end users.

Best,

f

 

[Damjan]

I have had a look at the signal module and the example

and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

I think acording to the Posix Thread specs, signals are only delevered to
the process and never to threads... I could be wrong though...

 

[Bengt Richter]

I have had a look at the signal module and the example
and came to the conclusion that the example wont work
if you try to do this in a thread.

So is there a chance similar code will work in a thread?

Do you have a specific use in mind? E.g., I believe there are things you can
do in the main thread that won't work in others, and other things
can be solved by appropriate communication between threads, etc.,
but without more clues it's hard to discuss it. I didn't look at
the example because I don't want to guess what "similar code" you
really are interested in ;-)

Regards,
Bengt Richter

 

[Jean Brouwers]

Fernando,

Just curious, does 'gtk/WX' in your message below mean wxPython?

If so, does this signal handling code actually work with wxPython?

/Jean Brouwers

 

[Fernando Perez]

Fernando,

Just curious, does 'gtk/WX' in your message below mean wxPython?
Yes.

If so, does this signal handling code actually work with wxPython?>

It does, but not in a generic manner: this is code for ipython to support
matplotlib's WX backend in an interactive shell. It allows you to type into
ipython plotting commands which cause matplotlib to open a WX plotting window,
and the interactive terminal continues to function. You can have multiple WX
plotting windows open, and the command line keeps on chugging.

But this relies on a special collaborative hack between matplotlib and ipython.
matplotlib, in its WX and GTK backends (Tk doesn't need this) has a special
flag to indicate who is in control of the mainloop. In standalone scripts,
everything works in the typical manner. But if ipython comes in, it will set
this flag, telling matplotlib to keep off the mainoop.

It's pretty hackish, but it works in practice pretty well.

here's the relevant matplotlib WX code (trimmed of docstring):

def show():

for figwin in Gcf.get_all_fig_managers():
figwin.frame.Show()
figwin.canvas.realize()
figwin.canvas.draw()

if show._needmain and not matplotlib.is_interactive():
wxapp.MainLoop()
show._needmain = False
show._needmain = True

When ipython starts up, it sets show._needmain to False, so that the Mainloop()
call is never made. You can look at the whole code from ipython if you wish,
it's in IPython/Shell.py.

best,

f

 

[Jean Brouwers]

Quite interesting, I'll check the Shell.py for more details. Thank you.

/Jean Brouwers

 

[Antoon Pardon]

Do you have a specific use in mind?

Any code that can block/run for unbounded time (in extention code)
and you wish to interrupt after a certain time out.

One thing where it could be usefull is the Queue module.

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.

 

[Peter Hansen]

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.

I'm fairly sure that the Queue uses an internal Event
(or REvent?) to signal when space or a new item is
available, so I believe your description (and possibly
conclusion) above is wrong. There should be no
"periodical check", as that would imply polling. Check
the source if you're interested.

-Peter

 

[Antoon Pardon]

I'm fairly sure that the Queue uses an internal Event
(or REvent?) to signal when space or a new item is
available, so I believe your description (and possibly
conclusion) above is wrong. There should be no
"periodical check", as that would imply polling. Check
the source if you're interested.

I did check the source, I just didn't study it carefully
and got my understanding mostly from the comments.
But anyway here is the relevant part and IMO we have
a polling loop here.


class Queue:

...

def get(self, block=True, timeout=None):
"""Remove and return an item from the queue.

If optional args 'block' is true and 'timeout' is None (the default),
block if necessary until an item is available. If 'timeout' is
a positive number, it blocks at most 'timeout' seconds and raises
the Empty exception if no item was available within that time.
Otherwise ('block' is false), return an item if one is immediately
available, else raise the Empty exception ('timeout' is ignored
in that case).
"""
if block:
if timeout is None:
# blocking, w/o timeout, i.e. forever
self.esema.acquire()
elif timeout >= 0:
# waiting max. 'timeout' seconds.
# this code snipped is from threading.py: _Event.wait():
# Balancing act: We can't afford a pure busy loop, so
# we
# have to sleep; but if we sleep the whole timeout time,
# we'll be unresponsive. The scheme here sleeps very
# little at first, longer as time goes on, but never
# longer
# than 20 times per second (or the timeout time
# remaining).
delay = 0.0005 # 500 us -> initial delay of 1 ms
endtime = _time() + timeout
while 1:
if self.esema.acquire(0):
break
remaining = endtime - _time()
if remaining <= 0: #time is over and no element arrived
raise Empty
delay = min(delay * 2, remaining, .05)
_sleep(delay) #reduce CPU usage by using a sleep

 

[Tim Peters]

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

 

[Bengt Richter]

I did check the source, I just didn't study it carefully
and got my understanding mostly from the comments.
But anyway here is the relevant part and IMO we have
a polling loop here.

It looks like you are right, at least on NT, where it is a shame,
since thread_nt.h only uses WaitForSingleObject with INFINITE timeout
specified, and it would seem the ideal timeout support API could be provided.
Maybe the lock acquire method could have an optional keyword arg timeout=floatingseconds,
and for NT that could be converted to milliseconds and used to wait for the mutex
with a non-inifinite wait. But it's platform dependent what low level OS support
there is for locks with timeouts. However, a win32 solution should benefit
a fair proportion of users, if many windows users do threading.

class Queue:

...

def get(self, block=True, timeout=None):
"""Remove and return an item from the queue.

If optional args 'block' is true and 'timeout' is None (the default),
block if necessary until an item is available. If 'timeout' is
a positive number, it blocks at most 'timeout' seconds and raises
the Empty exception if no item was available within that time.
Otherwise ('block' is false), return an item if one is immediately
available, else raise the Empty exception ('timeout' is ignored
in that case).
"""
if block:
if timeout is None:
# blocking, w/o timeout, i.e. forever
self.esema.acquire()
elif timeout >= 0:
# waiting max. 'timeout' seconds.
# this code snipped is from threading.py: _Event.wait():
# Balancing act: We can't afford a pure busy loop, so
# we
# have to sleep; but if we sleep the whole timeout time,
# we'll be unresponsive. The scheme here sleeps very
# little at first, longer as time goes on, but never
# longer
# than 20 times per second (or the timeout time
# remaining).
delay = 0.0005 # 500 us -> initial delay of 1 ms
endtime = _time() + timeout
while 1:
if self.esema.acquire(0):
break
remaining = endtime - _time()
if remaining <= 0: #time is over and no element arrived
raise Empty
delay = min(delay * 2, remaining, .05)
_sleep(delay) #reduce CPU usage by using a sleep

So, it would seem this kind of thing could be hidden in platform-specific
files where it was really necessary. Probably the people who can do it are
too busy ;-)

Regards,
Bengt Richter

 

[Bengt Richter]

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

Would it be a big deal to give the acquire method an optional
timeout=floating_seconds keyword arg, and have e.g. thread_nt.h use
the timeout parameter in WaitForSingleObject? This could ripple up
to Condition.aquire etc. and provide improved waiting over polling.
(Of course, there's probably a number of polling processes going on
all the time in the average windows session, but why add ;-)

Everything else is built on those, and CPython's thread implementation
is extremely portable-- and easy to port --as a result.

Do you think just a lock timeout would make it significantly harder?

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

So what do you think about a lock timeout. Just that would let you build
efficient terminatable substitutes for sleep and other timing things.

Regards,
Bengt Richter

 

[Tim Peters]

[Bengt Richter]

Would it be a big deal to give the acquire method an optional
timeout=floating_seconds keyword arg, and have e.g. thread_nt.h use
the timeout parameter in WaitForSingleObject? This could ripple up
to Condition.aquire etc. and provide improved waiting over polling.
(Of course, there's probably a number of polling processes going on
all the time in the average windows session, but why add ;-) ....
Do you think just a lock timeout would make it significantly harder? ....
So what do you think about a lock timeout. Just that would let you
build efficient terminatable substitutes for sleep and other timing things.

I rarely use timeouts, and, in the cases I do, haven't seen a
measurable burden due to the current wake-up-20-times-a-second
approach. So I have no motivation to change anything here.

Someone who does would have to go thru Python's 11 platform-specific
thread wrappers (these are C files in the Python/ directory, with
names of the form thread_PLATFORM.h), and figure out how to do it for
all of them -- or successfully argue that Python should no longer
support threads on those platforms for which they don't know how to
add the new core lock functionality -- or successfully argue (this one
is closer to impossible than unlikely) that platforms are free to
ignore the timeout argument.

 

[Antoon Pardon]

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

 

[Tim Peters]

[Uncle Timmy, explains why Python requires so little of platform
threads]

[Antoon Pardon]

I don't fault the current Queue implementation. I think your arguments
are very strong

I don't <0.5 wink>. Threading support in Python is forever frustrated
by the seeming need not to make trouble for the oddball thread
implementations we have but aren't even sure anyone uses anymore. For
example, the Python core could benefit from exploiting
platform-supplied thread-local-storage gimmicks. But we never move in
that direction, because the prospects of implementing it for all the
existing thread_PLATFORM.h wrappers appear too dim. Instead we rolled
our own implementation of thread-local storage, again building on no
more than "the Python lock". It's not particularly efficient, and
especially not after I fixed a critical thread race in it just a few
weeks ago, effectively serializing all lookups.

If Python *could* assume, e.g., that only pthreads boxes and Windows
are still interesting (it's clearly impossible that we could get away
with supporting a set that doesn't include those two; it's not clearly
impossible that we could get away with supporting only those two),
then we could assume a much richer set of platform-supplied threading
primitives to build on.

and I'm not arguing that the current Queue implementation
should be replaced by a dozen none portable system dependent
implementation.

That's OK -- the only *effective* away to make that argument would

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.

Who's "you"? It can't be me. Since I normally run on Windows, I pay
no attention to the signal module, let alone stay up nights plotting
to make it harder to live with. Guido is another matter; search
Google for, e.g, quotes like

Threads and signals don't mix. Period. (Only half a smiley.

and

I admit that I hate signals so badly that whenever I needed to wait
for a child to finish I would always structure the program around this
need (even when coding in C).

and

Why? I don't think hating signals disqualifies me from understanding
their problems.

and

I've always been reluctant about the fact that we had a signal module
at all -- it's not portable (no non-Unix system supports it well), doesn't
interact well with threads, etc., etc.; however, C programmers have
demanded some sort of signal support and I caved in long ago when
someone contributed a reasonable approach. I don't regret it like
lambda, but I think it should only be used by people who really know
about the caveats.

and

I wish we could invent a Python signal API that only lets you do one
of these simple things.

I confess I had a similar hatred of signals in my Unixish days (they
weren't portable, weren't reliable, & usually created debugging
nightmares much worse than the problems uses of signals were
introduced "to solve"), but Guido is the one who'll stab you in the

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.

That's certainly true. OTOH, I've never written, or worked with, an
app where, for a given Queue, some threads used timeouts but others
didn't. It seems strained to me. Then again, I'm not sure I've ever
worked on a real app where any thread used a timeout gimmick with a
Queue.

most-things-that-are-possible-shouldn't-be-done-ly y'rs - tim

 

[Antoon Pardon]

[Uncle Timmy, explains why Python requires so little of platform
threads]

[Antoon Pardon]

I don't fault the current Queue implementation. I think your arguments
are very strong

I don't <0.5 wink>. Threading support in Python is forever frustrated
by the seeming need not to make trouble for the oddball thread
implementations we have but aren't even sure anyone uses anymore. For
example, the Python core could benefit from exploiting
platform-supplied thread-local-storage gimmicks. But we never move in
that direction, because the prospects of implementing it for all the
existing thread_PLATFORM.h wrappers appear too dim. Instead we rolled
our own implementation of thread-local storage, again building on no
more than "the Python lock". It's not particularly efficient, and
especially not after I fixed a critical thread race in it just a few
weeks ago, effectively serializing all lookups.

If Python *could* assume, e.g., that only pthreads boxes and Windows
are still interesting (it's clearly impossible that we could get away
with supporting a set that doesn't include those two; it's not clearly
impossible that we could get away with supporting only those two),
then we could assume a much richer set of platform-supplied threading
primitives to build on.

Couldn't it be possible to have a general solution that works on
any kind of box and provide (or let interested parties provide)
an implementation that is better suited for particular boxes?

Who's "you"? It can't be me. Since I normally run on Windows, I pay
no attention to the signal module, let alone stay up nights plotting
to make it harder to live with. Guido is another matter; search
Google for, e.g, quotes like

[ quotes from Guido ]

Sorry about that, that was the general you meaning those that decide
what gets into python and what not. And yes I understand Guido has
some religious convictions and these influence on what he allows
in python and what not.

I confess I had a similar hatred of signals in my Unixish days (they
weren't portable, weren't reliable, & usually created debugging
nightmares much worse than the problems uses of signals were
introduced "to solve"), but Guido is the one who'll stab you in the
back today. I'll just cheer him on <wink>.

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.

That's certainly true. OTOH, I've never written, or worked with, an
app where, for a given Queue, some threads used timeouts but others
didn't. It seems strained to me. Then again, I'm not sure I've ever
worked on a real app where any thread used a timeout gimmick with a
Queue.

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.

 

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

 

[Antoon Pardon]

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