Hi Mark, On Jan 29, 2008 5:31 AM, Marc Lehmann <[EMAIL PROTECTED]> wrote: <snip>
> Might not work on windows, but pipes don't work there anyways. > Windows? What's that? :) <snip> > > Lots of connections with keep alive firing requests every so often. Each > > request requires some amount of CPU. Single threaded without processing, > I > > handle 35,000 request-responses/second. With processing, it drops to > about > > 5000 request-responses/second. > > Then new-conenction processing should indeed not be that much of a > problem. > You could even do totally weird stuff like running an accept in a loop > in round-robin fashion, e.g. on int(seconds) + 0 == thread 0, int(seconds) > + > 0.1 == thread 1 etc.. or something like that. > > That woudl have a constant overhead of 10 syscalls/s, but would get rid of > any communication overhead. > > (thats usually best if you do have quite a lot of connections, but > requires > tuning). That's a good idea. But if thread A (also loop A) decides to release its accept loop for hand off to thread B/loop B, I'll have to stop its watcher on loop A and add a watcher on loop B -- all from thread A (unless I use pipes, etc). Thus I think I'd have to add locking around all libev calls (or use pipes, etc)... or am I overlooking something? if conenctions are rare enough, the using-a-pipe trick might work best > because you don't care about overhead much there and just want to avoid > extra processing in each thread. Or perhaps that's what you're saying here? Move the accept watcher around and use pipes to tell the next loop to take ownership? Cheers, Eric
_______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
