Optimal multithread model
christophe at meessen.net
Mon Mar 15 11:48:54 CET 2010
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
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
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...
Size: 3277 bytes
Desc: S/MIME Cryptographic Signature
More information about the libev