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
[email protected]
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
