On Wed, Jan 09, 2008 at 10:20:13AM -0800, Eric Brown <[EMAIL PROTECTED]> wrote:
> wasn't always clear to me as to whether the concerns were about kqueue
> or about the way libev uses kqueue. Hence my question. :)
>
> Assuming I go with libev (likely), I'm developing on leopard but my
> target is freebsd. If there's some amount of testing you need, let me
> know.
Not really, by now, I know mostly what to expect. It was just my initial
suprirse to see how broken kqueue really is, in practise, because nobody
has seemed to try to use it as a replacement for poll/select in "normal"
programs.
> >What do you mean with "kqueue in non-polling mode"? afaik, kqueue only
> >supports a polling mode, and this is what both libevent and libev use.
>
> I'm talking about kevent(..., const struct timespec *timeout). Since I
> don't care about signals, fork events, etc. - all I care about is
> sockets - I don't think I want a 0 timeout in the call to kevent(). I
> see ev_set_io_collect_interval and I'm guessing this is what controls
> that?
>
> So by polling, all I meant was use of kevent with a 0 timeout.
I don't see why you want to rule out kevent with a zero timeout. The way
to avoid a zero timeout is to call ev_set_timeout_collect_interval (_not_
io), because the timeout parameter is tied to the timer handling (when put
this way its obvious :)
I am, however, curious as why you'd want to avoid kevent calls with a
zero timeout? Under normal operations, libev will not call libevent with
a zero timeout, but if it does, its usually for good reasons (and then
you cannot avoid it), and without understanding exactly what problem to
solve, I would suggest against setting any of the collect intervals - they
are very specific, advanced functions not normally necessary to achieve
specific performance (they can improve efficiency, e.g. at powresaving, at
the expense of latency, which should be a rare thing tor equire for a busy
server).
But then, if you need it, its there. Just think twice before using it
without knowing exactly why you need it.
> Thanks! I'm being told by a customer to use kqueue. At least with
> libev I can easily switch to something else if it doesn't work out.
Even without recompiling (and to some extent, also with libevent :).
> BTW, I'm told I need to support 1000s of connections. But my suspicion
> is that reality may be in the low 100s. On a fast server, do you have
> any idea where the cross-over is between poll/select and kqueue
Thats hard to say: select and poll on bsds are implemented differently, and
usually are slower no matter what, so the break even point would be at or
near 0 connections :)
It all depends on how you use it, of course: if most of your connections are
active, then select can be quite adequate, if most of your connections are
idle (the more common case) then select will likely be rather bad even at a
few dozen connections.
And again, if you app spends seconds processing each conenction, then the
slowdown caused by select will not be noticable, either.
In general, I would *expect* kqueue to compare fabvourably in all cases
against select, and certainly with a few hundred connections.
> performance? I see your benchmarks, but I don't think they compare
> different mechanisms.
The libevent homepage has two graphs comparing different mechanisms. They are
pretty adequate to show the basic different between select and another
mechanism, but the break-even point depends on many external factors.
In any case, if you want a second opinion on a problem, feel free to
present your problem here (its usually easier than verifying a solution to
an unknown problem), thats what the mailinglist is for, so don't hold back.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED]
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
libev mailing list
libev@lists.schmorp.de
http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
