On Tue, Nov 13, 2007 at 01:53:33PM -0800, Larry Lewis <[EMAIL PROTECTED]> wrote: > 1. What is this libev library?
Its a drop-in replacement for libevent. While it provides a libevent emulation API, it also has a new api that fixes most (maybe all) of the actual and perceived api problems with libevent. It is also faster, at least with epoll and timers being involved, uses less memory etc. etc. Benchmark and documentation is currently linked from here: http://libev.schmorp.de/ > 2. How does it differ from libevent? It offers a completely new, incompatible API with different design goals but also emulates libevent, at leats its event core parts. It is also easily embeddable for those people who need this functionality and wildly configurable. It does not feature evbuffer, evtags, evhttp or evdns, but the libevent source files implementing those can be used without any changes with libev. In fact, the only "release" file so far is actually a libevent tarball patched by replacing the libevent event handling with the libev files and keeping all else. The high degree of compatibility also makes it trivial to do the same for any upcoming 1.4 release. > Which is recommended for general usage on Linux? Decidedly both of them, depending on your goal and needs: - libevent has seen vastly more testing than libev (especially outside linux, which should always be an option). - libev has a much more efficient epoll implementation, and much faster timers, and less arbitrary limitations (as in the type of combinations of fd events are allowed etc.) - libevent isn't embeddable, libev is - libevent is 100% compatible to libevent, libev isn't, only emulating the most visible parts - if libevent works fine for you, its a safe, available fallback - if the libev api appeals to you more than the libevent api, its the way to go. etc. etc. If libevent works for you, you could try out libev, too, using its emulation API. In fact, when you keep developing for libevent you lose nothing, as you can use either library as you want. > 3. If it is a separate library, why is it being discussed on the > libevent mailing list? Shouldn't there be a separate list for this > (libev-users)? The plan by both the libev developer (me) and the libevent maintainers at the moment is to integrate libev (ideas, parts, or full) into libevent, which makes it on-topic on libevent. Also, the new API was developed together with the existing libevent users, as libev does not (at the moment) compete as a separate "product" or solution, but is aimed at providing a better libevent for the future. If this plan dies, then it would be more than appropriate to move discussions to another mailinglist, as libevent would then not progress towards the better API developed here but instead keep its interface, and discussions about changes would not belong on this mailinglist anymore (as in the past). On the other hand, most of the design is finished by now, and so the amount of discussion has gone down quite a bit. Let me thank the libevent users again here for helping me design the new API, all your input was very important. > Niels et all, great work on the 1.4.0 release -- especially the separate > libraries and doxygen documentation. Hmm.. is 1.4.0 even released yet? I only see the beta atm. -- The choice of a Deliantra, the free code+content MORPG -----==- _GNU_ http://www.deliantra.net ----==-- _ generation ---==---(_)__ __ ____ __ Marc Lehmann --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] -=====/_/_//_/\_,_/ /_/\_\ _______________________________________________ Libevent-users mailing list Libevent-users@monkey.org http://monkeymail.org/mailman/listinfo/libevent-users
