Optimal multithread model

[Christophe Meessen]

Hello,

I'm new to this list and just discovered the existence of libev this 
morning. So forgive me if this is a FAQ.

It looks like libev is designed to have one thread calling the ev_loop 
and executing the callbacks (assumed to be fast and never blocking).
If it is to be used for a server processing requests, the callbacks 
would collect the data of the request, and once complete, would queue 
the request so that worker thread may process it.

This is a straightforward design but it is not performance optimal when 
requests take a very short time to execute and the system is very loaded 
(many threads/process). This due to passing the request to another 
thread for processing. If the system is well loaded, it may take a 
significant time until the worker thread is given the CPU by the 
scheduler to process the request.

A more efficient method is the have the callback process the request 
itself. But some requests may take a long time to execute. So trick is 
to make the worker threads waiting to be able to monitor. When the 
monitoring thread detects an event, it signals the worker thread pool, 
telling them in this way that it is about to leave monitoring activity, 
and then starts to execute the callback. When done, it goes back into 
the pool trying to take over monitoring again. If the callback was very 
fast to execute, there is a good chance that the thread is back to the 
pool before another thread was given the opportunity by the scheduler to 
take over monitoring. Otherwise, it waits for its turn to get back to 
monitoring.

This multi thread model reduces request processing latency and supports 
callbacks with long time time to execute.

My understanding is that it would simply require the addition of a 
ev_monitoring() function which would be called by the worker threads. 
The ev_monitoring() function would return when an event is detected and 
the information needed to invoke the callback. The ev_monitoring would 
contain a condition variable used to regulate access to the effective 
monitoring task.

Some tweaks are required to ensure that there is always at least one 
thread actively monitoring or ready to take over monitoring. Callbacks 
should be queued if there is not enough working threads.

I could not see how this could be implemented with the current libev 
API. Did I miss something ?





-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3277 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20100315/b070fe7a/attachment.bin>