Fwd: Driving a thread pool from libev

Rick van Rein rick at openfortress.nl
Sat Feb 14 15:47:01 CET 2015


Hi,

> Excellent solution, it indeed avoid memcpy().

Thanks :-D

Conceptually the most logical model would be if libev would run multiple callbacks, each running in workers from the thread pool; and if it would use this mechanism to avoid starting multiple such callbacks on a single watcher.

> When you say "yeild()", it's some notification like ev_async_send(), right?

Not quite.  My thinking was that a main thread could spark off multiple callback threads, but these may not have run when the main thread loops back for another poll() invocation.  This would be sure to give all sparked-off threads an opportunity to remove the revents from the watcher.  Only threads that don’t act on their watcher's revents in time would be temporarily removed from the poll() list.  When the threaded callback finished, they would of course be added back in the poll() list.

The ideal is to run this pthread_yield() once per thread, just before returning to poll() — calling it from every callback function is possible, but wasteful as a single round over all threads is sufficient for each invocation of poll().  I don’t know yet if there are macro’s I can define to do that.

I’m thinking even further… the main thread could simply be one from the thread pool.  It would start off other slaves, until there’s more work then it has slaves for, in which case it would degrade itself to a slave.  Finishing slaves would take out one further event in turn, until the last is consumed; by that time, the slave promotes itself to be the new master, and returns to poll().  This makes threads continue to run in many cases, which means that the opportunity for lock-free or spinlock-based control is high.  Only when a thread really needs to wait would it be beneficial to wait for locks.  Sort of the “sleeping barber” setup, where clients volunteer as barbers :)

This stuff is fun :-D

It’s a pitty libev doesn’t do all this yet though; it feels like a natural extension to me.

Cheers,
-Rick



More information about the libev mailing list