Antoon Pardon <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
