Re: [Caml-list] Smart ways to implement worker threads

[Goswin von Brederlow <goswin-v-b@web.de>]

Romain Beauxis <toots@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.