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
ev_async.
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@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
