Hi everyone! Thanks to many people's hard work, Libevent 2.0 has now had its first beta release. You can download it from:
http://www.monkey.org/~provos/libevent-2.0.5-beta.tar.gz http://www.monkey.org/~provos/libevent-2.0.5-beta.tar.gz.sig Don't forget to validate the signature. The complete list of changes is available in the ChangeLog file, included with the distribution. *** What's new: Some highlights include: - The evdns module now uses the regular logging system - The evbuffer backend is now more efficient in how it packs bytes when reading. - The bufferevent rate-limiting logic has a few more features to help mix it with existing code. - Debugging mode now catches attempts to mix edge-triggered and non-edge triggered events. - There's a new evbuffer_copyout() function that acts like evbuffer_remove(), but without draining the buffer. - The request and reply members of rpc_req_generic are now exposed, for use by extensions to the RPC protocol. [Shuo Chen] - DNS errors that occur during bbufferevent_connect_hostname are now visible to user code. [Christopher Davis] - There's a new mode on bufferevents where, if you're using deferred callbacks, you can have the bufferevent callbacks executed without holding the lock on the bufferevent. [Joachim Bauch] And of course, - Bugfixes far too numerous to mention here. Check out the ChangeLog file for full details. Interface changes since 2.0.4-alpha are: - The singal_assign() and signal_new() macros are gone. These were added in 2.0.1 as an analogy to the new event_assign() and event_new(), but they were deprecated as soon as they were added in favor of evsignal_assign() and evsignal_new(). - The maximum number of events that can be added to read or write on a single fd is now limited to 65535. In 2.0.4-alpha, the the limit was INT_MAX. In 1.4.x, the limit was "1 reading, 1 writing". - The internal API for generated evrpc files is slightly different, to accommodate Shuo Chen's changes. *** Future: Libevent 2.0.x-rc and beyond. Libevent 2.0 is now in feature-freeze (we don't want to add any more features to it), hack-freeze (no clever backend rewrites, refactorings, or major performance hacks), and API freeze (all code written to work with the documented APIs of Libevent 2.0.5-beta should continue to work with future versions of Libevent). We might change our minds about any of the above if there turn out to be exceptionally good reasons to do so; this is an aspiration, not a promise. ;) I'm currently hoping to spend my (sadly limited) Libevent time over the next month or so hunting bugs and trying to improve the documentation, so we can get a release candidate out. After that, we'll keep fixing reported bugs in the release candidates until one is finally ready, and that will be the first official stable Libevent 2.0.x release. Somewhere in there, we'll fork off a new bugfix-only branch for work on 2.0.x, and we'll start accepting feature patches again for 2.1. My apologies to everybody who's been working on features that didn't get included in 2.0, especially Christopher Davis, Etienne Samson, Martin Scholl, and Valery Kholodkov. Mostly this is our fault for not replying to big complex patches fast enough. I hope we can get stuff straightened out enough to get the features you want into 2.1. When we fork the 2.1 branch, I'll send out some email trying to figure out where everybody's please-merge-this stuff stands. Also, I hope we can get 2.1 out on a faster dev cycle than we managed with the (much-delayed) 2.0. *** Acknowledgements Many thanks to everybody who contributed code, suggestions, or bug reports, including but not limited to Brodie Thiesfield, Christopher Davis, Dagobert Michelsen, Doug Cuthbertson, Frank Denis, Gernot Tenchio, Gilad Benjamini, Giuseppe Scrivano, Jardel Weyrich, Joachim Bauch, Patrick Galbraith, Pierre Phaneuf, Sebastian Hahn, Sebastian Sjöberg, Shuo Chen, Tao Feng, Trond Norbye, William Ahern and Zack Weinberg. peace, -- Nick Mathewson *********************************************************************** To unsubscribe, send an e-mail to majord...@freehaven.net with unsubscribe libevent-users in the body.
