Queue.Queue-like class without the busy-wait

Paul Rubin http
Tue Mar 29 07:30:19 EST 2005


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.

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.

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.



More information about the Python-list mailing list