Queue.Queue-like class without the busy-wait

[Antoon Pardon]

Op 2005-03-25, Paul Rubin schreef <http>:
> Antoon Pardon <apardon at forel.vub.ac.be> writes:
>> > I meant a semaphore to synchronize the queue when adding or removing
>> > objects.
>> 
>> Last I looked there was a lock used for that.
>
> OK, that amounts to the same thing.
>  
>> The loop is only for when you cant remove or add an element immediatly
>> and there is a timeout.
>
>> > Timeout would be handled with sigalarm or select.
>> 
>> How is select going to help? IMO you can't put a Queue in a select call.
>> And it is doubtfull if working with sigalarm will do the trick.
>
> You could open a socket to your own loopback port and then select on
> it, or something like that.  The select call takes a timeout parameter.

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.

It would require carefull coding, since you want to prevent the thread
blocking because of select returning indicating it could be read, but
between the select and the actual read an other thread already consumed
the byte.

>> First of all is the problem the signal module in python is very limited.
>> IIRC all signals are routed to the main thread. So breaking a lock
>> by having the thread signaled is impossible in python.
>
> 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.

There is also the problem you can't direct which thread will
aquire the lock. Suppose you have two threads waiting on a
lock, one plain, one with a timeout. Your signal handler
kicks in and releases the lock. There is a good chance
the first thread will now aquire the thread and the thread
that used a timeout will continue to be blocked.