Driving a thread pool from libev

Rick van Rein rick at openfortress.nl
Sat Feb 14 10:10:40 CET 2015


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?


Rick van Rein

More information about the libev mailing list