Driving a thread pool from libev

Marc Lehmann schmorp at schmorp.de
Sun Feb 15 01:26:09 CET 2015


On Sat, Feb 14, 2015 at 01:51:32PM +0100, Rick van Rein <rick at openfortress.nl> wrote:
>  * Then the event loop could yield() before it relaunches poll(), and give the worker threads a chance to perform their read().

Most systems today have multiple cpus (or cores). What you describe only
really makes sense on a uniprocessor system, where your whole approach of
using multiple threads would make no sense.

Of course, if you wanted to do that, libev already supports that -
register an ev_check watcher that checks your async flag (you likely want
atomic operations and not a spinlock, too...) and calls whatever yield
function you deem appropriate (on many modern systems such as linux, there
is no usable yield call for your purpose - pthread/sched_yield can and
will take out your thread for a looong time).

>  * In the cases where the poll() returns work with the “async processing in progress” flag set, it would temporarily remove the file descriptor from the poll() fdset, until ev_async_done() is called.

For poll, you can just call ev_io_stop, which is pretty lightweight. Of
course, your workload is unlikely to be efficient with poll as backend, and
ev_io_stop needs to make kernel calls with kqueue or epoll for example (it
tries to avoid them, but it won't be able to in your case).

Now, if you think poll() as backend is good enough for you, I would assume
using one thread per tls connection would be an o.k. model, since it
simplifies design a lot and you obviously don't have many concurrent
connections.

> But indeed, I’m not sure this is worth the effort.  I just see an
> opportunity that might improve libev and thought it might be good to
> mention it; if it saves a little for many libev users, it could still
> make sense.

Frankly, I think you need to do a lot more research first - it's pretty
clear that you don't understand computers very well from an efficiency
standpoint (judging from the confused way you throw around terms that make
little sense).

It's true that libev is a very low-level library (and small, too), meaning
you have to understand what is going on and it will only solve one problem
for you, namely I/O notifications and timers - maybe a higher level I/O
framework might be better for you: it might be less efficient, but easier
to use and doesn't require you to be good at thread or event programming.

Otherwise, proposing wild models that are completely unrealistic is not an
opportunity to improve anything but yourself.

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