Queue.Queue-like class without the busy-wait

[Paul Rubin]

Antoon Pardon <apardon at forel.vub.ac.be> writes:
> Well maybe you could use an os.pipe as a timeout lock then. When the lock is
> instantiated you put one byte in it. Aquiring the lock is implemented by
> reading one byte, releasing the lock is implemented by writing a byte.
> Aquiring the lock with a timeout would make use of select.

Hmm, if I understand what you're saying, you'd need a separate pipe
for every lock.  Interesting idea but I think it would burn too many
file descriptors if you used a lot of them.  My mentioning select also
is showing my age.  That was the way of doing short sleeps before
usleep became widespread.

> > A signal handler in the main thread could release a lock that the
> > thread is waiting on.
> 
> This wouldn't work. A thread would have no way knowing for what
> purpose the lock was released, because the lock was released
> by the thread holding the lock or because the signal handler
> released the lock, both would look the same for the thread
> aquiring the lock.

Yes, you'd need a separate lock for each blocked thread.  There would
be a list of locks waiting for timeouts and the sigalarm handler would
release any for which a wakeup was due.  You could use a priority
queue to maintain the timeout list, so that adding or servicing a
timeout would be O(log n).

The current implementation appears to wake up every few msec (50 msec
maximum if the thread stays blocked a long time) and check if the
timeout has expired.  If you have 1000 threads doing that, it can
burn a fair amount of cycles.