Hi Marc, On Jan 9, 2008, at 7:58 AM, Marc Lehmann wrote:
> On Wed, Jan 09, 2008 at 01:20:35AM -0800, Eric Brown <[EMAIL PROTECTED] > > wrote: >> Anyway, I read a number of concerns about libev & kqueue. > > What concerns? libev supports kqueue just fine... It is kqueue that > is making > problems on most BSDs, though. There were a few comments in the libev docs and mailing list. It 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. >> Since all I care about are sockets, can I get libev to use kqueue >> in an >> efficient non-polling mode? Or am I better off looking at libevent or >> using kqueue directly? > > 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. >> Sorry, I'm new to libev and kqueue - more used to using select() >> directly or other higher level APIs. But libev looks really great. > > Thanks. While, of course, I think that libev has a lot of advantages > over > libevent (such as a more rational API (espeically when > multithreading) and > higher performance), libevent is certainly adequate to the job as > well. > > You should probably look at the libevent example program, and the > libev > documentation (which also has examples) and choose the one that > appeals most > to you. > > If you are only interested in sockets and simple timeouts, then both > libraries have the same feature set (although understanding how > timeouts > work in libevent can be difficult, it certainly was for me). > > libevent example: http://monkey.org/~provos/libevent/event-test.c > libevent docs: http://monkey.org/~provos/libevent/doxygen/ > libev docs: http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod > > If you insist on using kqueue everywhere (watch out, its buggy on > most os > x releases even for sockets), then this will give you an event loop > using > kqueue in libev, whenever kqueue is available: > > #include <ev.h> > > struct ev_loop *loop = > ev_loop_new ( > ev_recommended_backends () | EVBACKEND_KQUEUE > ); > > assert ((loop, "libev initialisation failed")); 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. 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 performance? I see your benchmarks, but I don't think they compare different mechanisms. Cheers, Eric _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
