multi-threading

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


Hi Mark,

On Jan 29, 2008 5:31 AM, Marc Lehmann <schmorp at schmorp.de> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.schmorp.de/pipermail/libev/attachments/20080129/2fa05d10/attachment-0001.htm 


More information about the libev mailing list