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

_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev

Reply via email to