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