Will python ever have signalhandlers in threads?

[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
have been to supply a patch doing all the work yourself anyway <wink>.

> 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
back today.  I'll just cheer him on <wink>.

> 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