cuberite/libevent
1
0
Fork 0
mirror of https://github.com/cuberite/libevent.git synced 2025-09-10 04:50:37 -04:00
Code Issues Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Nick Mathewson 2010-12-09 12:17:58 -05:00
parent 57689c4484
commit 18adc3f015
1 changed files with 47 additions and 17 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

64
whatsnew-2.0.txt
View File

@ -211,9 +211,7 @@ What's New In Libevent 2.0 so far:
2.8. evthread_* functions for thread-safe structures. 2.8. evthread_* functions for thread-safe structures.
Libevent structures can now be built with locking support. You can enable Libevent structures can now be built with locking support. This code
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
makes it safe to add, remove, and activate events on an event base from a 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 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 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 If you want threading support and you're using Windows, you can just
call evthread_use_windows_threads(). 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 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 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 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. the event loop.
To make an evbuffer or a bufferevent object threadsafe, call its To make an evbuffer or a bufferevent object threadsafe, call its
_enable_locking() function. *_enable_locking() function.
The HTTP api is not currently threadsafe. 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 redundant adds and deletes, and performs no more operations than necessary
at the kernel level. 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 3.2. Improved notification on Linux
When we need to wake the event loop up from another thread, we use 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 3.3. Windows: better support for everything
Bufferevents on windows can use a new mechanism (off-by-default; see below) 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 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 via the IOCP API. This should be much faster than using event-based
notification. 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 event are now done with O(1) hash tables rather than O(lg n) red-black
trees. 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 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. actually a way to tell for certain whether a socket is writable with IOCP.
Libevent 2.1 may add a multithreaded WaitForMultipleEvents-based 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. Needless to say, this is a terrible interface for networked IO.
Now, evbuffers are implemented as a linked list of memory chunks, like 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 most Unix kernels use for network IO. (See Linux's skbuf interfaces,
linked list and removed from the front, so that we don't ever need or *BSD's mbufs). Data is added at the end of the linked list and
realloc huge chunks or memmove the whole buffer contents. 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 interfaces (or WSASend/WSARecv on Windows) to do IO on multiple chunks at
once with a single system call. once with a single system call.
@ -505,13 +516,13 @@ What's New In Libevent 2.0 so far:
6. Other improvements 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. 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 Libevent 2.0 tries harder to resist DNS answer-sniping attacks than
earlier versions of evdns. See comments in the code for full details. 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 internal RNG to generate DNS transaction IDs, so you don't need to supply
your own. your own.
6.1.3. Getaddrinfo support 6.1.3. DNS: Getaddrinfo support
There's now an asynchronous getaddrinfo clone, evdns_getaddrinfo(), There's now an asynchronous getaddrinfo clone, evdns_getaddrinfo(),
to make the results of the evdns functions more usable. It doesn't 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 Bufferevents provide bufferevent_connect_hostname(), which combines
the name lookup and connect operations. 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 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, 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 TCP connections. Just use the evconnlistener_*() functions in the
event2/listener.h header. 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 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 can use the evutil_secure_rng_*() functions to access a fairly secure
random stream of bytes. 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. Infrastructure improvements
7.1. Better unit test framework 7.1. Better unit test framework