Driving a thread pool from libev

echo fatmck at 163.com
Sat Feb 14 10:37:18 CET 2015

I think that my application is doing a similar work like yours.

In my application, user requests are received from main thread, then the 
requests are sent to data thread workers which will do some database 
queries, and then results are sent back to main thread in which reponses 
are made to users.

Here are how I implements this:
1) Each worker thread has its own ev_loop and a ev_async object. The 
worker thread will call ev_run() to waiting notification of ev_async.
2) Each worker thread has a circle buffer (some thing like a pipe) for 
receiving the request data from main thread.
3) When main thread got a new request, it find an idle worker and write 
the request data to the worker's circle-buffer and notify the worker's 
4) The worker will be notified in ev_run() and call the callback 
function in which it read the request data from circle buffer and do 
database queries.
5) Each worker thread has a circle buffer for sending result data to 
main thread and another ev_async object. The database query result will 
send to main thread in the same mechanism as step 3.
6) The main thread are waiting ev_async notification using ev_run(). So 
the main thread will be notified and read the result data in callback.

My English is not very good, hope this helpful.

在 2015年02月14日 17:10, Rick van Rein 写道:
> Hello,
> I am trying to drive a thread pool from libev, but the design appears to be impossible; or has anyone no this list done this before?
> The application: a TLS Pool [1], with worker threads that read(), then encrypt or decrypt, then write().  The workers should be part of a thread pool.  And, assuming that read() is a bit costly [2], I am trying to do even that operation in the worker threads.
> 	[1] http://tlspool.arpa2.net
> 	[2] when the data is not buffered, and also because data would flow through an intermediate buffer causing an extra copy operation
> When work is offloaded to the thread pool, the callback from libev can return and would hopefully cause other work to be queued, thus keeping the thread pool occupied with encryption/decryption.  The problem is, I am not sure if libev will avoid triggering an object that has already been queued, since poll() and friends will return a read opportunity over and over again.  And AFAIK I cannot tell libev to temporarily stop calling back on a watcher, except by taking it out completely — which I presume is an expensive operation.
> The current design uses a thread for each TLS connection, which is wasteful of memory, and this is why I am looking to create a thread pool with a limited number of shared workers.  I could decide to do the read() in the callback, if need be, but have not quite given up on a more efficient approach.  Has anyone on this list seen such a setup with libev?
> Thanks,
> Rick van Rein
> ARPA2.net
> _______________________________________________
> libev mailing list
> libev at lists.schmorp.de
> http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20150214/a4807c6a/attachment.html>

More information about the libev mailing list