[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [Libevent-users] Fun facts about Libevent 2.0.4-alpha
Hi,
Thanks for your work!
Another interesting fact about this release is that libevent-2 now
passes almost all of gevent's (www.gevent.org) test suite. The
previous alpha had a few failures in http server tests but 2.0.4 fixed
them!
There is one test that is still failing, but it's relatively minor:
In 1.4, if you send a request followed by some junk data, like this
request = '\r\n'.join((
'POST / HTTP/1.0',
'Host: localhost',
'Content-Length: 3',
'',
'a=a'))
fd.write(request)
# send some junk after the actual request
fd.write('01234567890123456789')
then libevent will call the user's callback, ignoring the junk.
In 2.0.4 this request does not trigger a callback.
On Thu, Mar 4, 2010 at 3:38 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
> Hi, all!
>
> As a followup to Niels's announcement, I'd like to go into a little
> more detail about what's up with the 2.0.4-alpha release.
>
> STATISTICS AND TRIVIA:
> * Libevent 2.0.4-alpha is about 4000 lines longer than Libevent
> 2.0.3-alpha. about 1700 of these are in tests and samples; the rest
> is in actual code.
>
> * Our unit test coverage has dipped a bit; in 2.0.3-alpha we were
> around 80.5%; now we're around 79.3% coverage. (Both numbers are from
> my Linux box.)
>
> * About 58% of Libevent's public functions, structures, and defines
> are now documented in my reference manual at
> http://www.wangafu.net/~nickm/libevent-book/ .
>
> WHAT'S NEW:
>
> For a full list of changes, see the ChangeLog on the website and
> distributed with Libevent 2.0.4-alpha. I'm only mentioning the stuff
> I find interesting here.
>
> * There are a ton of bugfixes, including a few memory corruption
> issues and race conditions. Everybody who's been writing
> multithreaded code should upgrade.
> * Bufferevents now support rate-limiting. You can rate-limit
> bufferevents individually, or in groups. Right now, this feature is
> underdocumented, since I suspect we'll want to tweak the APIs a bit
> before 2.0.x goes stable.
> * Our evdns_getaddrinfo() and evutil_getaddrinfo() functions now
> support looking at the /etc/hosts file, or local equivalent.
> * The http subsystem can now use evdns to do non-blocking hostname
> lookups for outgoing connections.
> * Libevent backends can now use a "changelist" feature to minimize
> calls to functions like epoll() and argument lengths to functions like
> kqueue(). Right now the epoll and kqueue backends use this feature;
> somebody could port evport and devpoll to do so as well.
> * There's a new event_get_struct_event_size() function so you can use
> event_assign() and friends without losing binary compatibility.
> * There are new event_get_callback(), event_get_callback_arg()
> functions to expose the remaining assigned members of an event, and an
> event_get_assignment() function to get every member of an event at
> once.
> * There's now support for running Libevent in a "debug mode" that can
> use a bit more memory and time, but detect some common programming
> errors. See the documentation for event_enable_debug_mode() for more
> information.
> * Libevent now uses a secure PRNG for the entropy that evdns needs to
> be secure. This is arc4random() on platforms that provide it, and our
> own copy of arc4random() on platforms that don't. You no longer need
> to replace the evdns transaction ID or random_bytes functions for
> security.
>
> WHAT'S GONE OR CHANGED:
>
> * If you have been manually providing locking functions with
> evthread_set_lock_create_callback and evthread_set_locking_callback,
> those functions are now deprecated. You should use the more
> future-proof evthread_set_lock_callbacks() function instead. (Or you
> could just use evthread_use_windows_threads() or
> evthread_use_pthreads(), and not worry about low-level locking details
> at all.)
> * The EVENT_FD and EVENT_SIGNAL macros are now deprecated.
> * Our vcproj files were completely incorrect; they built the wrong
> files with the wrong options. Nobody on the development team uses the
> MSVC IDE, so instead we're shipping makefiles for use with nmake.
> These we can actually inspect by hand, and use reproducibly.
> * We try to keep backward source compatibility with pre-2.0 versions
> of Libevent. Once Libevent 2.0.x is stable, we'll keep backward
> compatibility with that too. While 2.0.x is in alpha, though, we
> occasionally change or remove APIs introduced in earlier 2.0.x alphas
> so that we don't have to keep supporting bad ideas indefinitely.
> * The evhttp_connection_base_new() function now takes an optional
> evdns_base argument.
> * The flags argument of evdns_base_set_option() has been removed.
> * The EVUTIL_CHECK_FMT macro has been removed.
>
>
> hth,
> --
> Nick
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users in the body.
>
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users in the body.