Eric Brown yogieric.list at
Tue Jan 29 23:59:15 CET 2008

Hi Mark,

On Jan 29, 2008 5:31 AM, Marc Lehmann <schmorp at> wrote:

> Might not work on windows, but pipes don't work there anyways.

Windows? What's that? :)


> > 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?

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the libev mailing list