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
