Queue.Queue-like class without the busy-wait
apardon at forel.vub.ac.be
Tue Mar 29 14:53:05 CEST 2005
Op 2005-03-29, Paul Rubin schreef <http>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>> I'm not going to call my solution simple, but it wastes very few
>> cycles. if no thread is blocked on a lock, the select will just
>> block until that changes. No need for some kind of polling loop.
> I think I understand. My original idea was to use a heapq to be able
> to know exactly when the next pending timeout is due, and usleep for
> long enough to wake up at just the right time. Then you service the
> timeout, pop the heap to find when the next timeout after that is, and
> usleep again. No polling loops and no pipe. But it could be that
> someone inserts a new timeout while you're sleeping, that's due before
> you're scheduled to wake up. Your pipe scheme takes care of that,
> since any thread can write to the pipe and wake up the blocked thread
> at any time.
Right, that is the idea.
> Really, the culprit here is the weak signalling scheme in Python.
> There needs to be a way to send signals to threads, or raise
> asynchronous exceptions in them. There's been some discussion in
> sourceforge about that, but the issues involved are complex.
Well I have raised this issue before and as far as I understand,
the big problem seems to be the various kind of behaviour you
can get depending on what platform you are working, so writing
a module so that python programs behave the same on various
platforms seems a hell of a job.
So I decided not to pester the python people for this kind
of functionality, although I would very much like to have
I have been playing with the C-API and have somekind of
class that allows one thread to raise an excetion in an
other but that wouldn't be a solution here, since the
raised exception will not manifest itself while the
thread is in a C-function.
> I think the best bet for the short term is handling it at the C level,
> with sigalarm. Another way is to have chained sigalarm handlers in
> the main thread.
Possible, but I don't have the time to investigate that
More information about the Python-list