Driving a thread pool from libev

echo fatmck at 163.com
Sat Feb 14 14:46:16 CET 2015


Excellent solution, it indeed avoid memcpy().
When you say "yeild()", it's some notification like ev_async_send(), right?

在 2015年02月14日 20:51, Rick van Rein 写道:
> Hi Echo,
>
>> But in my opinion, the work in thread usually cost much more cpu time than read/write/malloc.
> Thanks for sharing that.  I am indeed wondering if my concerns aren’t a bit academic.  (I am in the desing phase, haven’t coded or measured, and since the app is to be portable it would be hard to actually draw general conclusions from measurements).
>
> I do see a nicer integration option of thread pools with libev though:
>   * The callbacks could set a flag “async processing in progress” on a watcher after setting up its queue entry in the callback.
>   * Then the event loop could yield() before it relaunches poll(), and give the worker threads a chance to perform their read().
>   * After the worker threads finish their read(), the threads would call an ev_async_done() function to turn off the processed watcher's “async processing” flag.
>   * 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.
>   * The “async processing in progress” flag could be protected with a simple spinlock, so it could all be userspace.
>
> 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.
>
> Cheers,
>   -Rick





More information about the libev mailing list