Driving a thread pool from libev

Marc Lehmann schmorp at schmorp.de
Sun Feb 15 01:08:02 CET 2015


On Sat, Feb 14, 2015 at 10:10:40AM +0100, Rick van Rein <rick at openfortress.nl> wrote:
> 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?

Many people have, apparently. Event loops and thread pools are mostly
orthogonal to each other - the most common models are to share one event
loop between many threads (e.g. leader-follower), use one event loop per
thread or some mixture (e.g. one accept() thread that distributes to
workers).

There are no known limitations in libev to realise whatever model you
want, but of course efficiency can vary.

> 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.

"Taking it out" is not usually an expensive operation in libev, but
the more "advanced" interfaces such as epoll or kqueue can make them
expensive.

A leader-follower approach usually avoids these issues: let one thread
drive libev until it hits an expensive operation, then pass the event loop
to another thread followed by doing whatever expensive stuff you need to
do.

> 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?

You are awfully quick to arrive at efficiency conclusions - especially
on modern systems, what seems "obviously inefficient" might actually be
faster - you really need to try it out to see what is more efficient.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list