Add stuff to whatsnew based on reading include changes since August.

1 files changed, 47 insertions, 17 deletions

diff --git a/whatsnew-2.0.txt b/whatsnew-2.0.txt
index 7be40bcf..3b4cfbdb 100644
--- a/whatsnew-2.0.txt
+++ b/whatsnew-2.0.txt
@@ -211,9 +211,7 @@ What's New In Libevent 2.0 so far:
 
 2.8. evthread_* functions for thread-safe structures.
 
-  Libevent structures can now be built with locking support.  You can enable
-  this on a per-event-base level by writing functions to implement mutexes
-  and thread IDs, and passing them to evthread_set_lock_callbacks.  This
+  Libevent structures can now be built with locking support.  This code
   makes it safe to add, remove, and activate events on an event base from a
   different thread.  (Previously, if you wanted to write multithreaded code
   with Libevent, you could only an event_base or its events in one thread at
@@ -227,6 +225,11 @@ What's New In Libevent 2.0 so far:
   If you want threading support and you're using Windows, you can just
   call evthread_use_windows_threads().
 
+  If you are using some locking system besides Windows and pthreads, You
+  can enable this on a per-event-base level by writing functions to
+  implement mutexes, conditions, and thread IDs, and passing them to
+  evthread_set_lock_callbacks and related functions in event2/thread.h.
+
   Once locking functions are enabled, every new event_base is created with a
   lock.  You can prevent a single event_base from being built with a lock
   disabled by using the EVENT_BASE_FLAG_NOLOCK flag in its
@@ -236,7 +239,7 @@ What's New In Libevent 2.0 so far:
   the event loop.
 
   To make an evbuffer or a bufferevent object threadsafe, call its
-  _enable_locking() function.
+  *_enable_locking() function.
 
   The HTTP api is not currently threadsafe.
 
@@ -287,6 +290,13 @@ What's New In Libevent 2.0 so far:
   redundant adds and deletes, and performs no more operations than necessary
   at the kernel level.
 
+  This logic is on for the kqueue backend, and available (but off by
+  default) for the epoll backend.  To turn it on for the epoll backend,
+  set the EVENT_BASE_FLAG_EPOLL_USE_CHANGELIST flag in the
+  event_base_cofig, or set the EVENT_EPOLL_USE_CHANGELIST environment
+  variable.  Doing this with epoll may result in weird bugs if you give
+  any fds closed by dup() or its variants.
+
 3.2. Improved notification on Linux
 
   When we need to wake the event loop up from another thread, we use
@@ -295,8 +305,8 @@ What's New In Libevent 2.0 so far:
 
 3.3. Windows: better support for everything
 
-  Bufferevents on windows can use a new mechanism (off-by-default; see below)
-  to send their data via windows overlapped IO and get their notifications
+  Bufferevents on Windows can use a new mechanism (off-by-default; see below)
+  to send their data via Windows overlapped IO and get their notifications
   via the IOCP API.  This should be much faster than using event-based
   notification.
 
@@ -309,7 +319,7 @@ What's New In Libevent 2.0 so far:
   event are now done with O(1) hash tables rather than O(lg n) red-black
   trees.
 
-  Unfortunately, the main windows backend is still select()-based: from
+  Unfortunately, the main Windows backend is still select()-based: from
   testing the IOCP backends on the mailing list, it seems that there isn't
   actually a way to tell for certain whether a socket is writable with IOCP.
   Libevent 2.1 may add a multithreaded WaitForMultipleEvents-based
@@ -333,11 +343,12 @@ What's New In Libevent 2.0 so far:
   Needless to say, this is a terrible interface for networked IO.
 
   Now, evbuffers are implemented as a linked list of memory chunks, like
-  most Unix kernels use for network IO.  Data is added at the end of the
-  linked list and removed from the front, so that we don't ever need
-  realloc huge chunks or memmove the whole buffer contents.
+  most Unix kernels use for network IO.  (See Linux's skbuf interfaces,
+  or *BSD's mbufs).  Data is added at the end of the linked list and
+  removed from the front, so that we don't ever need realloc huge chunks
+  or memmove the whole buffer contents.
 
-  To avoid multiple calls to read and write, we use the readv/writev
+  To avoid excessive calls to read and write, we use the readv/writev
   interfaces (or WSASend/WSARecv on Windows) to do IO on multiple chunks at
   once with a single system call.
 
@@ -505,13 +516,13 @@ What's New In Libevent 2.0 so far:
 
 6. Other improvements
 
-6.1. DNS
+6.1. DNS improvements
 
-6.1.1. IPv6 nameservers
+6.1.1. DNS: IPv6 nameservers
 
    The evdns code now lets you have nameservers whose addresses are IPv6.
 
-6.1.2: Better security.
+6.1.2. DNS: Better security
 
    Libevent 2.0 tries harder to resist DNS answer-sniping attacks than
    earlier versions of evdns.  See comments in the code for full details.
@@ -521,7 +532,7 @@ What's New In Libevent 2.0 so far:
    internal RNG to generate DNS transaction IDs, so you don't need to supply
    your own.
 
-6.1.3. Getaddrinfo support
+6.1.3. DNS: Getaddrinfo support
 
    There's now an asynchronous getaddrinfo clone, evdns_getaddrinfo(),
    to make the results of the evdns functions more usable.  It doesn't
@@ -536,7 +547,7 @@ What's New In Libevent 2.0 so far:
    Bufferevents provide bufferevent_connect_hostname(), which combines
    the name lookup and connect operations.
 
-6.1.4. No more evdns globals
+6.1.4. DNS: No more evdns globals
 
    Like an event base, evdns operations are now supposed to use an evdns_base
    argument.  This makes them easier to wrap for other (more OO) languages,
@@ -549,7 +560,7 @@ What's New In Libevent 2.0 so far:
    TCP connections.  Just use the evconnlistener_*() functions in the
    event2/listener.h header.
 
-   The listener code supports IOCP on windows if available.
+   The listener code supports IOCP on Windows if available.
 
 6.3. Secure RNG support
 
@@ -560,6 +571,25 @@ What's New In Libevent 2.0 so far:
    can use the evutil_secure_rng_*() functions to access a fairly secure
    random stream of bytes.
 
+6.4. HTTP
+
+   The evhttp uriencoding and uridecoding APIs have updated versions
+   that behave more correctly, and can handle strings with internal NULs.
+
+   The evhttp query parsing and URI parsing logic can now detect errors
+   more usefully.  Moreover, we include an actual URI parsing function
+   (evhttp_uri_parse()) to correctly parse URIs, so as to discourage
+   people from rolling their own ad-hoc parsing functions.
+
+   There are now accessor functions for the useful fields of struct http
+   and friends; it shouldn't be necessary to access them directly any
+   more.
+
+   Libevent now lets you declare support for all specified HTTP methods,
+   including OPTIONS, PATCH, and so on.  The default list is unchanged.
+
+   Numerous evhttp bugs also got fixed.
+
 7. Infrastructure improvements
 
 7.1. Better unit test framework