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