summaryrefslogtreecommitdiffstats
path: root/libevent/whatsnew-2.1.txt
diff options
context:
space:
mode:
Diffstat (limited to 'libevent/whatsnew-2.1.txt')
-rw-r--r--libevent/whatsnew-2.1.txt768
1 files changed, 768 insertions, 0 deletions
diff --git a/libevent/whatsnew-2.1.txt b/libevent/whatsnew-2.1.txt
new file mode 100644
index 0000000..c1f4df8
--- /dev/null
+++ b/libevent/whatsnew-2.1.txt
@@ -0,0 +1,768 @@
+ What's new in Libevent 2.1
+ Nick Mathewson
+
+0. Before we start
+
+0.1. About this document
+
+ This document describes the key differences between Libevent 2.0 and
+ Libevent 2.1, from a user's point of view. It's a work in progress.
+
+ For better documentation about libevent, see the links at
+ http://libevent.org/
+
+ Libevent 2.1 would not be possible without the generous help of
+ numerous volunteers. For a list of who did what in Libevent 2.1,
+ please see the ChangeLog!
+
+ NOTE: I am very sure that I missed some thing on this list. Caveat
+ haxxor.
+
+0.2. Where to get help
+
+ Try looking at the other documentation too. All of the header files
+ have documentation in the doxygen format; this gets turned into nice
+ HTML and linked to from the libevent.org website.
+
+ There is a work-in-progress book with reference manual at
+ http://www.wangafu.net/~nickm/libevent-book/ .
+
+ You can ask questions on the #libevent IRC channel at irc.oftc.net or
+ on the mailing list at libevent-users@freehaven.net. The mailing list
+ is subscribers-only, so you will need to subscribe before you post.
+
+0.3. Compatibility
+
+ Our source-compatibility policy is that correct code (that is to say,
+ code that uses public interfaces of Libevent and relies only on their
+ documented behavior) should have forward source compatibility: any
+ such code that worked with a previous version of Libevent should work
+ with this version too.
+
+ We don't try to do binary compatibility except within stable release
+ series, so binaries linked against any version of Libevent 2.0 will
+ probably need to be recompiled against Libevent 2.1.4-alpha if you
+ want to use it. It is probable that we'll break binary compatibility
+ again before Libevent 2.1 is stable.
+
+1. New APIs and features
+
+1.1. New ways to build libevent
+
+ We now provide an --enable-gcc-hardening configure option to turn on
+ GCC features designed for increased code security.
+
+ There is also an --enable-silent-rules configure option to make
+ compilation run more quietly with automake 1.11 or later.
+
+ You no longer need to use the --enable-gcc-warnings option to turn on
+ all of the GCC warnings that Libevent uses. The only change from
+ using that option now is to turn warnings into errors.
+
+ For IDE users, files that are not supposed to be built are now
+ surrounded with appropriate #ifdef lines to keep your IDE from getting
+ upset.
+
+ There is now an alternative cmake-based build process; cmake users
+ should see the relevant sections in the README.
+
+
+1.2. New functions for events and the event loop
+
+ If you're running Libevent with multiple event priorities, you might
+ want to make sure that Libevent checks for new events frequently, so
+ that time-consuming or numerous low-priority events don't keep it from
+ checking for new high-priority events. You can now use the
+ event_config_set_max_dispatch_interval() interface to ensure that the
+ loop checks for new events either every N microseconds, every M
+ callbacks, or both.
+
+ When configuring an event base, you can now choose whether you want
+ timers to be more efficient, or more precise. (This only has effect
+ on Linux for now.) Timers are efficient by default: to select more
+ precise timers, use the EVENT_BASE_FLAG_PRECISE_TIMER flag when
+ constructing the event_config, or set the EVENT_PRECISE_TIMER
+ environment variable to a non-empty string.
+
+ There is an EVLOOP_NO_EXIT_ON_EMPTY flag that tells event_base_loop()
+ to keep looping even when there are no pending events. (Ordinarily,
+ event_base_loop() will exit as soon as no events are pending.)
+
+ Past versions of Libevent have been annoying to use with some
+ memory-leak-checking tools, because Libevent allocated some global
+ singletons but provided no means to free them. There is now a
+ function, libevent_global_shutdown(), that you can use to free all
+ globally held resources before exiting, so that your leak-check tools
+ don't complain. (Note: this function doesn't free non-global things
+ like events, bufferevents, and so on; and it doesn't free anything
+ that wouldn't otherwise get cleaned up by the operating system when
+ your process exit()s. If you aren't using a leak-checking tool, there
+ is not much reason to call libevent_global_shutdown().)
+
+ There is a new event_base_get_npriorities() function to return the
+ number of priorities set in the event base.
+
+ Libevent 2.0 added an event_new() function to construct a new struct
+ event on the heap. Unfortunately, with event_new(), there was no
+ equivalent for:
+
+ struct event ev;
+ event_assign(&ev, base, fd, EV_READ, callback, &ev);
+
+ In other words, there was no easy way for event_new() to set up an
+ event so that the event itself would be its callback argument.
+ Libevent 2.1 lets you do this by passing "event_self_cbarg()" as the
+ callback argument:
+
+ struct event *evp;
+ evp = event_new(base, fd, EV_READ, callback,
+ event_self_cbarg());
+
+ There's also a new event_base_get_running_event() function you can
+ call from within a Libevent callback to get a pointer to the current
+ event. This should never be strictly necessary, but it's sometimes
+ convenient.
+
+ The event_base_once() function used to leak some memory if the event
+ that it added was never actually triggered. Now, its memory is
+ tracked in the event_base and freed when the event_base is freed.
+ Note however that Libevent doesn't know how to free any information
+ passed as the callback argument to event_base_once is still something
+ you'll might need a way to de-allocate yourself.
+
+ There is an event_get_priority() function to return an event's
+ priority.
+
+ By analogy to event_base_loopbreak(), there is now an
+ event_base_loopcontinue() that tells Libevent to stop processing
+ active event callbacks, and re-scan for new events right away.
+
+ There's a function, event_base_foreach_event(), that can iterate over
+ every event currently pending or active on an event base, and invoke a
+ user-supplied callback on each. The callback must not alter the events
+ or add or remove anything to the event base.
+
+ We now have an event_remove_timer() function to remove the timeout on
+ an event while leaving its socket and/or signal triggers unchanged.
+ (If we were designing the API from scratch, this would be the behavior
+ of "event_add(ev, NULL)" on an already-added event with a timeout. But
+ that's a no-op in past versions of Libevent, and we don't want to
+ break compatibility.)
+
+ You can use the new event_base_get_num_events() function to find the
+ number of events active or pending on an event_base. To find the
+ largest number of events that there have been since the last call, use
+ event_base_get_max_events().
+
+ You can now activate all the events waiting for a given fd or signal
+ using the event_base_active_by_fd() and event_base_active_by_signal()
+ APIs.
+
+ On backends that support it (currently epoll), there is now an
+ EV_CLOSED flag that programs can use to detect when a socket has
+ closed without having to read all the bytes until receiving an EOF.
+
+1.3. Event finalization
+
+1.3.1. Why event finalization?
+
+ Libevent 2.1 now supports an API for safely "finalizing" events that
+ might be running in multiple threads, and provides a way to slightly
+ change the semantics of event_del() to prevent deadlocks in
+ multithreaded programs.
+
+ To motivate this feature, consider the following code, in the context
+ of a mulithreaded Libevent application:
+
+ struct connection *conn = event_get_callback_arg(ev);
+ event_del(ev);
+ connection_free(conn);
+
+ Suppose that the event's callback might be running in another thread,
+ and using the value of "conn" concurrently. We wouldn't want to
+ execute the connection_free() call until "conn" is no longer in use.
+ How can we make this code safe?
+
+ Libevent 2.0 answered that question by saying that the event_del()
+ call should block if the event's callback is running in another
+ thread. That way, we can be sure that event_del() has canceled the
+ callback (if the callback hadn't started running yet), or has waited
+ for the callback to finish.
+
+ But now suppose that the data structure is protected by a lock, and we
+ have the following code:
+
+ void check_disable(struct connection *connection) {
+ lock(connection);
+ if (should_stop_reading(connection))
+ event_del(connection->read_event);
+ unlock(connection);
+ }
+
+ What happens when we call check_disable() from a callback and from
+ another thread? Let's say that the other thread gets the lock
+ first. If it decides to call event_del(), it will wait for the
+ callback to finish. But meanwhile, the callback will be waiting for
+ the lock on the connection. Since each threads is waiting for the
+ other one to release a resource, the program will deadlock.
+
+ This bug showed up in multithreaded bufferevent programs in 2.1,
+ particularly when freeing bufferevents. (For more information, see
+ the "Deadlock when calling bufferevent_free from an other thread"
+ thread on libevent-users starting on 6 August 2012 and running through
+ February of 2013. You might also like to read my earlier writeup at
+ http://archives.seul.org/libevent/users/Feb-2012/msg00053.html and
+ the ensuing discussion.)
+
+1.3.2. The EV_FINALIZE flag and avoiding deadlock
+
+ To prevent the deadlock condition described above, Libevent
+ 2.1.3-alpha adds a new flag, "EV_FINALIZE". You can pass it to
+ event_new() and event_assign() along with EV_READ, EV_WRITE, and the
+ other event flags.
+
+ When an event is constructed with the EV_FINALIZE flag, event_del()
+ will not block on that event, even when the event's callback is
+ running in another thread. By using EV_FINALIZE, you are therefore
+ promising not to use the "event_del(ev); free(event_get_callback_arg(ev));"
+ pattern, but rather to use one of the finalization functions below to
+ clean up the event.
+
+ EV_FINALIZE has no effect on a single-threaded program, or on a
+ program where events are only used from one thread.
+
+
+ There are also two new variants of event_del() that you can use for
+ more fine-grained control:
+ event_del_noblock(ev)
+ event_del_block(ev)
+ The event_del_noblock() function will never block, even if the event
+ callback is running in another thread and doesn't have the EV_FINALIZE
+ flag. The event_del_block() function will _always_ block if the event
+ callback is running in another thread, even if the event _does_ have
+ the EV_FINALIZE flag.
+
+ [A future version of Libevent may have a way to make the EV_FINALIZE
+ flag the default.]
+
+1.3.3. Safely finalizing events
+
+ To safely tear down an event that may be running, Libevent 2.1.3-alpha
+ introduces event_finalize() and event_free_finalize(). You call them
+ on an event, and provide a finalizer callback to be run on the event
+ and its callback argument once the event is definitely no longer
+ running.
+
+ With event_free_finalize(), the event is also freed once the finalizer
+ callback has been invoked.
+
+ A finalized event cannot be re-added or activated. The finalizer
+ callback must not add events, activate events, or attempt to
+ "resucitate" the event being finalized in any way.
+
+ If any finalizer callbacks are pending as the event_base is being
+ freed, they will be invoked. You can override this behavior with the
+ new function event_base_free_nofinalize().
+
+1.4. New debugging features
+
+ You can now turn on debug logs at runtime using a new function,
+ event_enable_debug_logging().
+
+ The event_enable_lock_debugging() function is now spelled correctly.
+ You can still use the old "event_enable_lock_debuging" name, though,
+ so your old programs shouldnt' break.
+
+ There's also been some work done to try to make the debugging logs
+ more generally useful.
+
+1.5. New evbuffer functions
+
+ In Libevent 2.0, we introduced evbuffer_add_file() to add an entire
+ file's contents to an evbuffer, and then send them using sendfile() or
+ mmap() as appropriate. This API had some drawbacks, however.
+ Notably, it created one mapping or fd for every instance of the same
+ file added to any evbuffer. Also, adding a file to an evbuffer could
+ make that buffer unusable with SSL bufferevents, filtering
+ bufferevents, and any code that tried to read the contents of the
+ evbuffer.
+
+ Libevent 2.1 adds a new evbuffer_file_segment API to solve these
+ problems. Now, you can use evbuffer_file_segment_new() to construct a
+ file-segment object, and evbuffer_add_file_segment() to insert it (or
+ part of it) into an evbuffer. These segments avoid creating redundant
+ maps or fds. Better still, the code is smart enough (when the OS
+ supports sendfile) to map the file when that's necessary, and use
+ sendfile() otherwise.
+
+ File segments can receive callback functions that are invoked when the
+ file segments are freed.
+
+ The evbuffer_ptr interface has been extended so that an evbuffer_ptr
+ can now yield a point just after the end of the buffer. This makes
+ many algorithms simpler to implement.
+
+ There's a new evbuffer_add_buffer() interface that you can use to add
+ one buffer to another nondestructively. When you say
+ evbuffer_add_buffer_reference(outbuf, inbuf), outbuf now contains a
+ reference to the contents of inbuf.
+
+ To aid in adding data in bulk while minimizing evbuffer calls, there
+ is an evbuffer_add_iovec() function.
+
+ There's a new evbuffer_copyout_from() variant function to enable
+ copying data nondestructively from the middle of a buffer.
+
+ evbuffer_readln() now supports an EVBUFFER_EOL_NUL argument to fetch
+ NUL-terminated strings from buffers.
+
+ There's a new evbuffer_set_flags()/evbuffer_clear_flags() that you can use to
+ set EVBUFFER_FLAG_DRAINS_TO_FD.
+
+1.6. New functions and features: bufferevents
+
+ You can now use the bufferevent_getcb() function to find out a
+ bufferevent's callbacks. Previously, there was no supported way to do
+ that.
+
+ The largest chunk readable or writeable in a single bufferevent
+ callback is no longer hardcoded; it's now configurable with
+ the new functions bufferevent_set_max_single_read() and
+ bufferevent_set_max_single_write().
+
+ For consistency, OpenSSL bufferevents now make sure to always set one
+ of BEV_EVENT_READING or BEV_EVENT_WRITING when invoking an event
+ callback.
+
+ Calling bufferevent_set_timeouts(bev, NULL, NULL) now removes the
+ timeouts from socket and ssl bufferevents correctly.
+
+ You can find the priority at which a bufferevent runs with
+ bufferevent_get_priority().
+
+ The function bufferevent_get_token_bucket_cfg() can retrieve the
+ rate-limit settings for a bufferevent; bufferevent_getwatermark() can
+ return a bufferevent's current watermark settings.
+
+ You can manually trigger a bufferevent's callbacks via
+ bufferevent_trigger() and bufferevent_trigger_event().
+
+ Also you can manually increment/decrement reference for bufferevent with
+ bufferevent_incref()/bufferevent_decref(), it is useful in situations where a
+ user may reference the bufferevent somewhere else.
+
+ Now bufferevent_openssl supports "dirty" shutdown (when the peer closes the
+ TCP connection before closing the SSL channel), see
+ bufferevent_openssl_get_allow_dirty_shutdown() and
+ bufferevent_openssl_set_allow_dirty_shutdown().
+
+ And also libevent supports openssl 1.1.
+
+1.7. New functions and features: evdns
+
+ The previous evdns interface used an "open a test UDP socket" trick in
+ order to detect IPv6 support. This was a hack, since it would
+ sometimes badly confuse people's firewall software, even though no
+ packets were sent. The current evdns interface-detection code uses
+ the appropriate OS functions to see which interfaces are configured.
+
+ The evdns_base_new() function now has multiple possible values for its
+ second (flags) argument. Using 1 and 0 have their old meanings, though the
+ 1 flag now has a symbolic name of EVDNS_BASE_INITIALIZE_NAMESERVERS.
+ A second flag is now supported too: the EVDNS_BASE_DISABLE_WHEN_INACTIVE
+ flag, which tells the evdns_base that it should not prevent Libevent from
+ exiting while it has no DNS requests in progress.
+
+ There is a new evdns_base_clear_host_addresses() function to remove
+ all the /etc/hosts addresses registered with an evdns instance.
+
+ Also there is evdns_base_get_nameserver_addr() for retrieve the address of
+ the 'idx'th configured nameserver.
+
+1.8. New functions and features: evconnlistener
+
+ Libevent 2.1 adds the following evconnlistener flags:
+
+ LEV_OPT_DEFERRED_ACCEPT -- Tells the OS that it doesn't need to
+ report sockets as having arrived until the initiator has sent some
+ data too. This can greatly improve performance with protocols like
+ HTTP where the client always speaks first. On operating systems
+ that don't support this functionality, this option has no effect.
+
+ LEV_OPT_REUSEABLE_PORT -- Indicates that we ask to allow multiple servers
+ to bind to the same port if they each set the option Ionly on Linux and
+ >=3.9)
+
+ LEV_OPT_DISABLED -- Creates an evconnlistener in the disabled (not
+ listening) state.
+
+ Libevent 2.1 changes the behavior of the LEV_OPT_CLOSE_ON_EXEC
+ flag. Previously, it would apply to the listener sockets, but not to
+ the accepted sockets themselves. That's almost never what you want.
+ Now, it applies both to the listener and the accepted sockets.
+
+1.9. New functions and features: evhttp
+
+ **********************************************************************
+ NOTE: The evhttp module will eventually be deprecated in favor of Mark
+ Ellzey's libevhtp library. Don't worry -- this won't happen until
+ libevhtp provides every feature that evhttp does, and provides a
+ compatible interface that applications can use to migrate.
+ **********************************************************************
+
+ Previously, you could only set evhttp timeouts in increments of one
+ second. Now, you can use evhttp_set_timeout_tv() and
+ evhttp_connection_set_timeout_tv() to configure
+ microsecond-granularity timeouts.
+
+ Also there is evhttp_connection_set_initial_retry_tv() to change initial
+ retry timeout.
+
+ There are a new pair of functions: evhttp_set_bevcb() and
+ evhttp_connection_base_bufferevent_new(), that you can use to
+ configure which bufferevents will be used for incoming and outgoing
+ http connections respectively. These functions, combined with SSL
+ bufferevents, should enable HTTPS support.
+
+ There's a new evhttp_foreach_bound_socket() function to iterate over
+ every listener on an evhttp object.
+
+ Whitespace between lines in headers is now folded into a single space;
+ whitespace at the end of a header is now removed.
+
+ The socket errno value is now preserved when invoking an http error
+ callback.
+
+ There's a new kind of request callback for errors; you can set it with
+ evhttp_request_set_error_cb(). It gets called when there's a request error,
+ and actually reports the error code and lets you figure out which request
+ failed.
+
+ You can navigate from an evhttp_connection back to its evhttp with the
+ new evhttp_connection_get_server() function.
+
+ You can override the default HTTP Content-Type with the new
+ evhttp_set_default_content_type() function
+
+ There's a new evhttp_connection_get_addr() API to return the peer
+ address of an evhttp_connection.
+
+ The new evhttp_send_reply_chunk_with_cb() is a variant of
+ evhttp_send_reply_chunk() with a callback to be invoked when the
+ chunk is sent.
+
+ The evhttp_request_set_header_cb() facility adds a callback to be
+ invoked while parsing headers.
+
+ The evhttp_request_set_on_complete_cb() facility adds a callback to be
+ invoked on request completion.
+
+ You can add linger-close for http server by passing
+ EVHTTP_SERVER_LINGERING_CLOSE to evhttp_set_flags(), with this flag server
+ read all the clients body, and only after this respond with an error if the
+ clients body exceed max_body_size (since some clients cannot read response
+ otherwise).
+
+ The evhttp_connection_set_family() can bypass family hint to evdns.
+
+ There are some flags available for connections, which can be installed with
+ evhttp_connection_set_flags():
+ - EVHTTP_CON_REUSE_CONNECTED_ADDR -- reuse connection address on retry (avoid
+ extra DNS request).
+ - EVHTTP_CON_READ_ON_WRITE_ERROR - try read error, since server may already
+ close the connection.
+
+ The evhttp_connection_free_on_completion() can be used to tell libevent to
+ free the connection object after the last request has completed or failed.
+
+ There is evhttp_request_get_response_code_line() if
+ evhttp_request_get_response_code() is not enough for you.
+
+ There are *evhttp_uri_parse_with_flags() that accepts
+ EVHTTP_URI_NONCONFORMANT to tolerate URIs that do not conform to RFC3986.
+ The evhttp_uri_set_flags() can changes the flags on URI.
+
+1.10. New functions and features: evutil
+
+ There's a function "evutil_secure_rng_set_urandom_device_file()" that
+ you can use to override the default file that Libevent uses to seed
+ its (sort-of) secure RNG.
+
+ The evutil_date_rfc1123() returns date in RFC1123
+
+ There are new API to work with monotonic timer -- monotonic time is
+ guaranteed never to run in reverse, but is not necessarily epoch-based. Use
+ it to make reliable measurements of elapsed time between events even when the
+ system time may be changed:
+ - evutil_monotonic_timer_new()/evutil_monotonic_timer_free()
+ - evutil_configure_monotonic_time()
+ - evutil_gettime_monotonic()
+
+ Use evutil_make_listen_socket_reuseable_port() to set SO_REUSEPORT (linux >=
+ 3.9)
+
+ The evutil_make_tcp_listen_socket_deferred() can make a tcp listener socket
+ defer accept()s until there is data to read (TCP_DEFER_ACCEPT).
+
+2. Cross-platform performance improvements
+
+2.1. Better data structures
+
+ We replaced several users of the sys/queue.h "TAILQ" data structure
+ with the "LIST" data structure. Because this data type doesn't
+ require FIFO access, it requires fewer pointer checks and
+ manipulations to keep it in line.
+
+ All previous versions of Libevent have kept every pending (added)
+ event in an "eventqueue" data structure. Starting in Libevent 2.0,
+ however, this structure became redundant: every pending timeout event
+ is stored in the timeout heap or in one of the common_timeout queues,
+ and every pending fd or signal event is stored in an evmap. Libevent
+ 2.1 removes this data structure, and thereby saves all of the code
+ that we'd been using to keep it updated.
+
+2.2. Faster activations and timeouts
+
+ It's a common pattern in older code to use event_base_once() with a
+ 0-second timeout to ensure that a callback will get run 'as soon as
+ possible' in the current iteration of the Libevent loop. We optimize
+ this case by calling event_active() directly, and bypassing the
+ timeout pool. (People who are using this pattern should also consider
+ using event_active() themselves.)
+
+ Libevent 2.0 would wake up a polling event loop whenever the first
+ timeout in the event loop was adjusted--whether it had become earlier
+ or later. We now only notify the event loop when a change causes the
+ expiration time to become _sooner_ than it would have been otherwise.
+
+ The timeout heap code is now optimized to perform fewer comparisons
+ and shifts when changing or removing a timeout.
+
+ Instead of checking for a wall-clock time jump every time we call
+ clock_gettime(), we now check only every 5 seconds. This should save
+ a huge number of gettimeofday() calls.
+
+2.3. Microoptimizations
+
+ Internal event list maintainance no longer use the antipattern where
+ we have one function with multiple totally independent behaviors
+ depending on an argument:
+ #define OP1 1
+ #define OP2 2
+ #define OP3 3
+ void func(int operation, struct event *ev) {
+ switch (op) {
+ ...
+ }
+ }
+ Instead, these functions are now split into separate functions for
+ each operation:
+ void func_op1(struct event *ev) { ... }
+ void func_op2(struct event *ev) { ... }
+ void func_op3(struct event *ev) { ... }
+
+ This produces better code generation and inlining decisions on some
+ compilers, and makes the code easier to read and check.
+
+2.4. Evbuffer performance improvements
+
+ The EVBUFFER_EOL_CRLF line-ending type is now much faster, thanks to
+ smart optimizations.
+
+2.5. HTTP performance improvements
+
+ o Performance tweak to evhttp_parse_request_line. (aee1a97 Mark Ellzey)
+ o Add missing break to evhttp_parse_request_line (0fcc536)
+
+2.6. Coarse timers by default on Linux
+
+ Due to limitations of the epoll interface, Libevent programs using epoll
+ have not previously been able to wait for timeouts with accuracy smaller
+ than 1 millisecond. But Libevent had been using CLOCK_MONOTONIC for
+ timekeeping on Linux, which is needlessly expensive: CLOCK_MONOTONIC_COARSE
+ has approximately the resolution corresponding to epoll, and is much faster
+ to invoke than CLOCK_MONOTONIC.
+
+ To disable coarse timers, and get a more plausible precision, use the
+ new EVENT_BASE_FLAG_PRECISE_TIMER flag when setting up your event base.
+
+3. Backend/OS-specific improvements
+
+3.1. Linux-specific improvements
+
+ The logic for deciding which arguements to use with epoll_ctl() is now
+ a table-driven lookup, rather than the previous pile of cascading
+ branches. This should minimize epoll_ctl() calls and make the epoll
+ code run a little faster on change-heavy loads.
+
+ Libevent now takes advantage of Linux's support for enhanced APIs
+ (e.g., SOCK_CLOEXEC, SOCK_NONBLOCK, accept4, pipe2) that allow us to
+ simultaneously create a socket, make it nonblocking, and make it
+ close-on-exec. This should save syscalls throughout our codebase, and
+ avoid race-conditions if an exec() occurs after a socket is socket is
+ created but before we can make it close-on-execute on it.
+
+3.2. Windows-specific improvements
+
+ We now use GetSystemTimeAsFileTime to implement gettimeofday. It's
+ significantly faster and more accurate than our old ftime()-based approach.
+
+3.3. Improvements in the solaris evport backend.
+
+ The evport backend has been updated to use many of the infrastructure
+ improvements from Libevent 2.0. Notably, it keeps track of per-fd
+ information using the evmap infrastructure, and removes a number of
+ linear scans over recently-added events. This last change makes it
+ efficient to receive many more events per evport_getn() call, thereby
+ reducing evport overhead in general.
+
+3.4. OSX backend improvements
+
+ The OSX select backend doesn't like to have more than a certain number
+ of fds set unless an "unlimited select" option has been set.
+ Therefore, we now set it.
+
+3.5. Monotonic clocks on even more platforms
+
+ Libevent previously used a monotonic clock for its internal timekeeping
+ only on platforms supporting the POSIX clock_gettime() interface. Now,
+ Libevent has support for monotonic clocks on OSX and Windows too, and a
+ fallback implementation for systems without monotonic clocks that will at
+ least keep time running forwards.
+
+ Using monotonic timers makes Libevent more resilient to changes in the
+ system time, as can happen in small amounts due to clock adjustments from
+ NTP, or in large amounts due to users who move their system clocks all over
+ the timeline in order to keep nagware from nagging them.
+
+3.6. Faster cross-thread notification on kqueue
+
+ When a thread other than the one in which the main event loop is
+ running needs to wake the thread running the main event loop, Libevent
+ usually writes to a socketpair in order to force the main event loop
+ to wake up. On Linux, we've been able to use eventfd() instead. Now
+ on BSD and OSX systems (any anywhere else that has kqueue with the
+ EVFILT_USER extension), we can use EVFILT_USER to wake up the main
+ thread from kqueue. This should be a tiny bit faster than the
+ previous approach.
+
+4. Infrastructure improvements
+
+4.1. Faster tests
+
+ I've spent some time to try to make the unit tests run faster in
+ Libevent 2.1. Nearly all of this was a matter of searching slow tests
+ for unreasonably long timeouts, and cutting them down to reasonably
+ long delays, though on one or two cases I actually had to parallelize
+ an operation or improve an algorithm.
+
+ On my desktop, a full "make verify" run of Libevent 2.0.18-stable
+ requires about 218 seconds. Libevent 2.1.1-alpha cuts this down to
+ about 78 seconds.
+
+ Faster unit tests are great, since they let programmers test their
+ changes without losing their train of thought.
+
+4.2. Finicky tests are now off-by-default
+
+ The Tinytest unit testing framework now supports optional tests, and
+ Libevent uses them. By default, Libevent's unit testing framework
+ does not run tests that require a working network, and does not run
+ tests that tend to fail on heavily loaded systems because of timing
+ issues. To re-enable all tests, run ./test/regress using the "@all"
+ alias.
+
+4.3. Modernized use of autotools
+
+ Our autotools-based build system has been updated to build without
+ warnings on recent autoconf/automake versions.
+
+ Libevent's autotools makefiles are no longer recursive. This allows
+ make to use the maximum possible parallelism to do the minimally
+ necessary amount of work. See Peter Miller's "Recursive Make
+ Considered Harmful" at http://miller.emu.id.au/pmiller/books/rmch/ for
+ more information here.
+
+ We now use the "quiet build" option to suppress distracting messages
+ about which commandlines are running. You can get them back with
+ "make V=1".
+
+4.4. Portability
+
+ Libevent now uses large-file support internally on platforms where it
+ matters. You shouldn't need to set _LARGEFILE or OFFSET_BITS or
+ anything magic before including the Libevent headers, either, since
+ Libevent now sets the size of ev_off_t to the size of off_t that it
+ received at compile time, not to some (possibly different) size based
+ on current macro definitions when your program is building.
+
+ We now also use the Autoconf AC_USE_SYSTEM_EXTENSIONS mechanism to
+ enable per-system macros needed to enable not-on-by-default features.
+ Unlike the rest of the autoconf macros, we output these to an
+ internal-use-only evconfig-private.h header, since their names need to
+ survive unmangled. This lets us build correctly on more platforms,
+ and avoid inconsistencies when some files define _GNU_SOURCE and
+ others don't.
+
+ Libevent now tries to detect OpenSSL via pkg-config.
+
+4.5. Standards conformance
+
+ Previous Libevent versions had no consistent convention for internal
+ vs external identifiers, and used identifiers starting with the "_"
+ character throughout the codebase. That's no good, since the C
+ standard says that identifiers beginning with _ are reserved. I'm not
+ aware of having any collisions with system identifiers, but it's best
+ to fix these things before they cause trouble.
+
+ We now avoid all use of the _identifiers in the Libevent source code.
+ These changes were made *mainly* through the use of automated scripts,
+ so there shouldn't be any mistakes, but you never know.
+
+ As an exception, the names _EVENT_LOG_DEBUG, _EVENT_LOG_MSG_,
+ _EVENT_LOG_WARN, and _EVENT_LOG_ERR are still exposed in event.h: they
+ are now deprecated, but to support older code, they will need to stay
+ around for a while. New code should use EVENT_LOG_DEBUG,
+ EVENT_LOG_MSG, EVENT_LOG_WARN, and EVENT_LOG_ERR instead.
+
+4.6. Event and callback refactoring
+
+ As a simplification and optimization to Libevent's "deferred callback"
+ logic (introduced in 2.0 to avoid callback recursion), Libevent now
+ treats all of its deferrable callback types using the same logic it
+ uses for active events. Now deferred events no longer cause priority
+ inversion, no longer require special code to cancel them, and so on.
+
+ Regular events and deferred callbacks now both descend from an
+ internal light-weight event_callback supertype, and both support
+ priorities and take part in the other anti-priority-inversion
+ mechanisms in Libevent.
+
+ To avoid starvation from callback recursion (which was the reason we
+ introduced "deferred callbacks" in the first place) the implementation
+ now allows an event callback to be scheduled as "active later":
+ instead of running in the current iteration of the event loop, it runs
+ in the next one.
+
+5. Testing
+
+ Libevent's test coverage level is more or less unchanged since before:
+ we still have over 80% line coverage in our tests on Linux, FreeBSD, NetBSD,
+ Windows, OSX.
+ There are some under-tested modules, though: we need to fix those.
+
+ And now we have CI:
+ - https://travis-ci.org/libevent/libevent
+ - https://ci.appveyor.com/project/nmathewson/libevent
+
+ And code coverage:
+ - https://coveralls.io/github/libevent/libevent
+
+ Plus there is vagrant boxes if you what to test it on more OS'es then
+ travis-ci allows, and there is a wrapper (in python) that will parse logs and
+ provide report:
+ - https://github.com/libevent/libevent-extras/blob/master/tools/vagrant-tests.py
+
+6. Contributing
+
+ From now we have contributing guide and checkpatch.sh.