Will python ever have signalhandlers in threads?

[Antoon Pardon]

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

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

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

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

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.

-- 
Antoon Pardon