Hi! http://data.plan9.de/libev-1.3e.tar.gz
is the first "release" (on a very low level of release) of the libev event core, which is a drop-in replacement for libevent, fixing API problems with a new API while providing libevent compatibility. See the http://cvs.schmorp.de/libev/README for a partial list of differences to libevent-1.3e. One of the major features is that it can be easily embedded into other programs without having to hack the source code (so upgrades are easy). See http://cvs.schmorp.de/libev/README.embed for an introduction on how to do this. The whole tarball is mostly identical to libevent-1.3e, with the following differences: - the event core (event.h sans tagging and buffer stuff) has been replaced by the libev code. - ev.h and event_compat.h header files will additonally be installed (if you want to use the event api you still need to include event.h) - "libevent" has been renamed to "libev" wherever I saw it. - the resulting libev library is not binary-compatible to any libevent version. - the regression test has some tests disabled (a few tests that rely on accessing the internal structure, and the priority tests as priorities are not supported by libev in the same way as event yet). - the core files are under a 2-clause bsd license, the files partially taken from libevent (even if basically nothing is left over by now) are under a 3-clause bsd license, making the whole thing 3-clause bsd licensed, as the original libevent. The buffer, tag, dns and http APIs are all identical to libevent (as the libevent code is used without change). The benchmarks are still favourable towards libev (http://libev.schmorp.de/bench.html), although some optimisations that were done to epoll had to be taken out due to some deficiencies in the epoll interface (which is, however, fully reflected in the benchmark document). The backends that are available right now: - select (tested on win32, linux, freebsd) - poll (tested on linux, freebsd) - epoll (tested on linux) - kqueue (tested on freebsd (and os x where it was disabled as with libevent))) This is the first release, one one can expect a lot of portability problems and of course some bugs, as the library itself hasn't been tested by many people and not very well overall, and certainly lacks the years of maturity of libevent (which, on the other hand, was a great place to look for portability problems and solutions to them, so one didn't need to reinvent the wheel). I tried to implement solutions to all the problems mentioned by users on this list both w.r.t. the libevent API as well as with the proposed libev API. Feedback would be highly appreciated. Regarding the future of libev: many people have voiced their opinion, and it seems that most people actually want an event library without anything else, and sometimes an embeddable event library. What the core is boils usually down to "what libev provides + event emulation" and sometimes includes the libevent buffer abstraction. So I wonder if it would indeed be better to make a standalone release of libev without the extra http, dns parts and so on (possibly including the buffer code). The advantage of a standalone release would be less bloat and less confusion about the two libraries. The disadvantage is that the libevent files cannot as easily be integrated into applications as the libev source files, so adding a feature that isn't there (such as evdns.c) is harder then ramoving it if it is there. Any feedback on this issue would be appreciated, too. Thanks a lot, and may it be helpful to somebody. -- 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
