Queue.Queue-like class without the busy-wait

Antoon Pardon 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
possibility now.

Antoon Pardon

More information about the Python-list mailing list