![]() Modules might have use for signals and how they might interfere. Like using a signal handler because you never know what other It usesĪ seperate thread with one pipe for a wakeup mechanisme. Well have a look at what I have written over the weekend. > A signal handler in the main thread could release a lock that the Op, Paul Rubin schreef : Antoon Pardon writes: Well maybe you could use an os.pipe as a timeout lock then. If you have 1000 threads doing that, it can Maximum if the thread stays blocked a long time) and check if the The current implementation appears to wake up every few msec (50 msec Queue to maintain the timeout list, so that adding or servicing a There wouldīe a list of locks waiting for timeouts and the sigalarm handler would Yes, you'd need a separate lock for each blocked thread. That was the way of doing short sleeps before Interesting idea but I think it would burn too manyįile descriptors if you used a lot of them. Hmm, if I understand what you're saying, you'd need a separate pipeįor every lock. That used a timeout will continue to be blocked.Īntoon Pardon writes: Well maybe you could use an os.pipe as a timeout lock then. The first thread will now aquire the thread and the thread ![]() Suppose you have two threads waiting on a There is also the problem you can't direct which thread willĪquire the lock. Released the lock, both would look the same for the thread Purpose the lock was released, because the lock was releasedīy the thread holding the lock or because the signal handler A thread would have no way knowing for what It would require carefull coding, since you want to prevent the threadīlocking because of select returning indicating it could be read, butīetween the select and the actual read an other thread already consumedĪ signal handler in the main thread could release a lock that the Reading one byte, releasing the lock is implemented by writing a byte.Īquiring the lock with a timeout would make use of select. Well maybe you could use an os.pipe as a timeout lock then. The select call takes a timeout parameter. You could open a socket to your own loopback port and then select on ![]() > Timeout would be handled with sigalarm or select. Op, Paul Rubin schreef : Antoon Pardon writes: > I meant a semaphore to synchronize the queue when adding or removing Know since I'm not familiar with the pthread specifications. The last time I experimented with a pthreads in C, locks didn'tīreak by signalling the thread. You may provide your own signal module, but that may not be enough. So breaking a lockīy having the thread signaled is impossible in python. IIRC all signals are routed to the main thread. How is select going to help? IMO you can't put a Queue in a select call.Īnd it is doubtfull if working with sigalarm will do the trick.įirst of all is the problem the signal module in python is very limited. Timeout would be handled with sigalarm or select. The loop is only for when you cant remove or add an element immediatly Last I looked there was a lock used for that. I meant a semaphore to synchronize the queue when adding or removing Can't it work the obvious wayĪnd how is this semaphore going to be released if the timeout is Op, Paul Rubin schreef : Antoon Pardon writes: > I've never checked this code but it wouldn't have occurred to me that ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |