Romain Beauxis <to...@rastageeks.org> writes: > Le samedi 17 juillet 2010 05:52:31, Goswin von Brederlow a écrit : >> Now I have a queue that I can include in select. The take function can >> be used by the worker threads. The main thread can use either take_all >> or process to save on syscalls or stick with take to ensure the queue >> does not starve the other FDs. >> >> Also I think I can use the EventFD to terminate a queue and wake up all >> listeners. Closing the EventFD should wake up any thread stuck in read >> and prevent any threads from becoming stuck in the future. Haven't >> tested that yet though. > > I don't see why you want to use EventFD and not Condition.wait/signal. In > particular, Condition.broadcast does exactly the last thing you mention.
Not quite. With a Condition.wait I can only wait on exactly one condition. With the EventFD I can use the Unix.file_descr together with other Unix.file_descr in Unix.select. That means I can wait for both new input to come in over the sockets or for results to become available in the queue with a single thread, which gets rid of quite some Mutexes. > Now, I don't understand why you asked for related modules and and the end > discard all of them and post your own implementation. Your issue is not that > complex you could have done that in the first place... I was fishing for solutions. There were some good ones and tanks for all the replies. They were not wasted. But none of them seem like a really good fit to the code as I have it in mind. Some reasons why that is so I only see now, after tasting the waters and testing things out. For example, and the reason why EventFD seem like the way to go NOW, I noticed that replies to requests are sometimes too large to be written out in a single go or simply come too fast to be written out without blocking. That means I have to write them out in multiple chunks and then sockets need to be protected so chunks from multiple replies don't get mixed together from different threads and so on. If I use a queue with EventFD instead of Condition.t then I can add the queue to the select loop and any thread can drop a reply job into that queue. The select thread will wake up, take the reply job, add the data to the sockets outgoing buffer and add the sockets FD to the select call and wait for it to be ready for writing. All without needing Mutexes to protect the socket or signals to wake up and restart the select since the select thread and only the select thread will be handling the sockets. MfG Goswin PS: I still haven't 100% decided yet what the best solution is but EventFD seems to lead currently. So if anyone has other ideas keep them coming. _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs