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