1                         What's new in Libevent 2.1
2                             Nick Mathewson
3
40. Before we start
5
60.1. About this document
7
8  This document describes the key differences between Libevent 2.0 and
9  Libevent 2.1, from a user's point of view.  It's a work in progress.
10
11  For better documentation about libevent, see the links at
12  http://libevent.org/
13
14  Libevent 2.1 would not be possible without the generous help of
15  numerous volunteers.  For a list of who did what in Libevent 2.1,
16  please see the ChangeLog!
17
18  NOTE: I am very sure that I missed some thing on this list.  Caveat
19  haxxor.
20
210.2. Where to get help
22
23  Try looking at the other documentation too.  All of the header files
24  have documentation in the doxygen format; this gets turned into nice
25  HTML and linked to from the libevent.org website.
26
27  There is a work-in-progress book with reference manual at
28  http://www.wangafu.net/~nickm/libevent-book/ .
29
30  You can ask questions on the #libevent IRC channel at irc.oftc.net or
31  on the mailing list at libevent-users@freehaven.net.  The mailing list
32  is subscribers-only, so you will need to subscribe before you post.
33
340.3. Compatibility
35
36  Our source-compatibility policy is that correct code (that is to say,
37  code that uses public interfaces of Libevent and relies only on their
38  documented behavior) should have forward source compatibility: any
39  such code that worked with a previous version of Libevent should work
40  with this version too.
41
42  We don't try to do binary compatibility except within stable release
43  series, so binaries linked against any version of Libevent 2.0 will
44  probably need to be recompiled against Libevent 2.1.4-alpha if you
45  want to use it.  It is probable that we'll break binary compatibility
46  again before Libevent 2.1 is stable.
47
481. New APIs and features
49
501.1. New ways to build libevent
51
52  We now provide an --enable-gcc-hardening configure option to turn on
53  GCC features designed for increased code security.
54
55  There is also an --enable-silent-rules configure option to make
56  compilation run more quietly with automake 1.11 or later.
57
58  You no longer need to use the --enable-gcc-warnings option to turn on
59  all of the GCC warnings that Libevent uses.  The only change from
60  using that option now is to turn warnings into errors.
61
62  For IDE users, files that are not supposed to be built are now
63  surrounded with appropriate #ifdef lines to keep your IDE from getting
64  upset.
65
66  There is now an alternative cmake-based build process; cmake users
67  should see the relevant sections in the README.
68
69
701.2. New functions for events and the event loop
71
72  If you're running Libevent with multiple event priorities, you might
73  want to make sure that Libevent checks for new events frequently, so
74  that time-consuming or numerous low-priority events don't keep it from
75  checking for new high-priority events.  You can now use the
76  event_config_set_max_dispatch_interval() interface to ensure that the
77  loop checks for new events either every N microseconds, every M
78  callbacks, or both.
79
80  When configuring an event base, you can now choose whether you want
81  timers to be more efficient, or more precise.  (This only has effect
82  on Linux for now.)  Timers are efficient by default: to select more
83  precise timers, use the EVENT_BASE_FLAG_PRECISE_TIMER flag when
84  constructing the event_config, or set the EVENT_PRECISE_TIMER
85  environment variable to a non-empty string.
86
87  There is an EVLOOP_NO_EXIT_ON_EMPTY flag that tells event_base_loop()
88  to keep looping even when there are no pending events.  (Ordinarily,
89  event_base_loop() will exit as soon as no events are pending.)
90
91  Past versions of Libevent have been annoying to use with some
92  memory-leak-checking tools, because Libevent allocated some global
93  singletons but provided no means to free them.  There is now a
94  function, libevent_global_shutdown(), that you can use to free all
95  globally held resources before exiting, so that your leak-check tools
96  don't complain.  (Note: this function doesn't free non-global things
97  like events, bufferevents, and so on; and it doesn't free anything
98  that wouldn't otherwise get cleaned up by the operating system when
99  your process exit()s.  If you aren't using a leak-checking tool, there
100  is not much reason to call libevent_global_shutdown().)
101
102  There is a new event_base_get_npriorities() function to return the
103  number of priorities set in the event base.
104
105  Libevent 2.0 added an event_new() function to construct a new struct
106  event on the heap.  Unfortunately, with event_new(), there was no
107  equivalent for:
108
109         struct event ev;
110         event_assign(&ev, base, fd, EV_READ, callback, &ev);
111
112  In other words, there was no easy way for event_new() to set up an
113  event so that the event itself would be its callback argument.
114  Libevent 2.1 lets you do this by passing "event_self_cbarg()" as the
115  callback argument:
116
117         struct event *evp;
118         evp = event_new(base, fd, EV_READ, callback,
119         event_self_cbarg());
120
121  There's also a new event_base_get_running_event() function you can
122  call from within a Libevent callback to get a pointer to the current
123  event.  This should never be strictly necessary, but it's sometimes
124  convenient.
125
126  The event_base_once() function used to leak some memory if the event
127  that it added was never actually triggered.  Now, its memory is
128  tracked in the event_base and freed when the event_base is freed.
129  Note however that Libevent doesn't know how to free any information
130  passed as the callback argument to event_base_once is still something
131  you'll might need a way to de-allocate yourself.
132
133  There is an event_get_priority() function to return an event's
134  priority.
135
136  By analogy to event_base_loopbreak(), there is now an
137  event_base_loopcontinue() that tells Libevent to stop processing
138  active event callbacks, and re-scan for new events right away.
139
140  There's a function, event_base_foreach_event(), that can iterate over
141  every event currently pending or active on an event base, and invoke a
142  user-supplied callback on each. The callback must not alter the events
143  or add or remove anything to the event base.
144
145  We now have an event_remove_timer() function to remove the timeout on
146  an event while leaving its socket and/or signal triggers unchanged.
147  (If we were designing the API from scratch, this would be the behavior
148  of "event_add(ev, NULL)" on an already-added event with a timeout. But
149  that's a no-op in past versions of Libevent, and we don't want to
150  break compatibility.)
151
152  You can use the new event_base_get_num_events() function to find the
153  number of events active or pending on an event_base. To find the
154  largest number of events that there have been since the last call, use
155  event_base_get_max_events().
156
157  You can now activate all the events waiting for a given fd or signal
158  using the event_base_active_by_fd() and event_base_active_by_signal()
159  APIs.
160
161  On backends that support it (currently epoll), there is now an
162  EV_CLOSED flag that programs can use to detect when a socket has
163  closed without having to read all the bytes until receiving an EOF.
164
1651.3. Event finalization
166
1671.3.1. Why event finalization?
168
169  Libevent 2.1 now supports an API for safely "finalizing" events that
170  might be running in multiple threads, and provides a way to slightly
171  change the semantics of event_del() to prevent deadlocks in
172  multithreaded programs.
173
174  To motivate this feature, consider the following code, in the context
175  of a mulithreaded Libevent application:
176
177        struct connection *conn = event_get_callback_arg(ev);
178        event_del(ev);
179        connection_free(conn);
180
181  Suppose that the event's callback might be running in another thread,
182  and using the value of "conn" concurrently.  We wouldn't want to
183  execute the connection_free() call until "conn" is no longer in use.
184  How can we make this code safe?
185
186  Libevent 2.0 answered that question by saying that the event_del()
187  call should block if the event's callback is running in another
188  thread.  That way, we can be sure that event_del() has canceled the
189  callback (if the callback hadn't started running yet), or has waited
190  for the callback to finish.
191
192  But now suppose that the data structure is protected by a lock, and we
193  have the following code:
194
195        void check_disable(struct connection *connection) {
196            lock(connection);
197            if (should_stop_reading(connection))
198                    event_del(connection->read_event);
199            unlock(connection);
200        }
201
202  What happens when we call check_disable() from a callback and from
203  another thread?  Let's say that the other thread gets the lock
204  first.  If it decides to call event_del(), it will wait for the
205  callback to finish.  But meanwhile, the callback will be waiting for
206  the lock on the connection.  Since each threads is waiting for the
207  other one to release a resource, the program will deadlock.
208
209  This bug showed up in multithreaded bufferevent programs in 2.1,
210  particularly when freeing bufferevents.  (For more information, see
211  the "Deadlock when calling bufferevent_free from an other thread"
212  thread on libevent-users starting on 6 August 2012 and running through
213  February of 2013.  You might also like to read my earlier writeup at
214  http://archives.seul.org/libevent/users/Feb-2012/msg00053.html and
215  the ensuing discussion.)
216
2171.3.2. The EV_FINALIZE flag and avoiding deadlock
218
219  To prevent the deadlock condition described above, Libevent
220  2.1.3-alpha adds a new flag, "EV_FINALIZE".  You can pass it to
221  event_new() and event_assign() along with EV_READ, EV_WRITE, and the
222  other event flags.
223
224  When an event is constructed with the EV_FINALIZE flag, event_del()
225  will not block on that event, even when the event's callback is
226  running in another thread.  By using EV_FINALIZE, you are therefore
227  promising not to use the "event_del(ev); free(event_get_callback_arg(ev));"
228  pattern, but rather to use one of the finalization functions below to
229  clean up the event.
230
231  EV_FINALIZE has no effect on a single-threaded program, or on a
232  program where events are only used from one thread.
233
234
235  There are also two new variants of event_del() that you can use for
236  more fine-grained control:
237     event_del_noblock(ev)
238     event_del_block(ev)
239  The event_del_noblock() function will never block, even if the event
240  callback is running in another thread and doesn't have the EV_FINALIZE
241  flag.  The event_del_block() function will _always_ block if the event
242  callback is running in another thread, even if the event _does_ have
243  the EV_FINALIZE flag.
244
245  [A future version of Libevent may have a way to make the EV_FINALIZE
246  flag the default.]
247
2481.3.3. Safely finalizing events
249
250  To safely tear down an event that may be running, Libevent 2.1.3-alpha
251  introduces event_finalize() and event_free_finalize(). You call them
252  on an event, and provide a finalizer callback to be run on the event
253  and its callback argument once the event is definitely no longer
254  running.
255
256  With event_free_finalize(), the event is also freed once the finalizer
257  callback has been invoked.
258
259  A finalized event cannot be re-added or activated.  The finalizer
260  callback must not add events, activate events, or attempt to
261  "resucitate" the event being finalized in any way.
262
263  If any finalizer callbacks are pending as the event_base is being
264  freed, they will be invoked.  You can override this behavior with the
265  new function event_base_free_nofinalize().
266
2671.4. New debugging features
268
269  You can now turn on debug logs at runtime using a new function,
270  event_enable_debug_logging().
271
272  The event_enable_lock_debugging() function is now spelled correctly.
273  You can still use the old "event_enable_lock_debuging" name, though,
274  so your old programs shouldnt' break.
275
276  There's also been some work done to try to make the debugging logs
277  more generally useful.
278
2791.5. New evbuffer functions
280
281  In Libevent 2.0, we introduced evbuffer_add_file() to add an entire
282  file's contents to an evbuffer, and then send them using sendfile() or
283  mmap() as appropriate.  This API had some drawbacks, however.
284  Notably, it created one mapping or fd for every instance of the same
285  file added to any evbuffer.  Also, adding a file to an evbuffer could
286  make that buffer unusable with SSL bufferevents, filtering
287  bufferevents, and any code that tried to read the contents of the
288  evbuffer.
289
290  Libevent 2.1 adds a new evbuffer_file_segment API to solve these
291  problems.  Now, you can use evbuffer_file_segment_new() to construct a
292  file-segment object, and evbuffer_add_file_segment() to insert it (or
293  part of it) into an evbuffer.  These segments avoid creating redundant
294  maps or fds.  Better still, the code is smart enough (when the OS
295  supports sendfile) to map the file when that's necessary, and use
296  sendfile() otherwise.
297
298  File segments can receive callback functions that are invoked when the
299  file segments are freed.
300
301  The evbuffer_ptr interface has been extended so that an evbuffer_ptr
302  can now yield a point just after the end of the buffer.  This makes
303  many algorithms simpler to implement.
304
305  There's a new evbuffer_add_buffer() interface that you can use to add
306  one buffer to another nondestructively.  When you say
307  evbuffer_add_buffer_reference(outbuf, inbuf), outbuf now contains a
308  reference to the contents of inbuf.
309
310  To aid in adding data in bulk while minimizing evbuffer calls, there
311  is an evbuffer_add_iovec() function.
312
313  There's a new evbuffer_copyout_from() variant function to enable
314  copying data nondestructively from the middle of a buffer.
315
316  evbuffer_readln() now supports an EVBUFFER_EOL_NUL argument to fetch
317  NUL-terminated strings from buffers.
318
319  There's a new evbuffer_set_flags()/evbuffer_clear_flags() that you can use to
320  set EVBUFFER_FLAG_DRAINS_TO_FD.
321
3221.6. New functions and features: bufferevents
323
324  You can now use the bufferevent_getcb() function to find out a
325  bufferevent's callbacks.  Previously, there was no supported way to do
326  that.
327
328  The largest chunk readable or writeable in a single bufferevent
329  callback is no longer hardcoded; it's now configurable with
330  the new functions bufferevent_set_max_single_read() and
331  bufferevent_set_max_single_write().
332
333  For consistency, OpenSSL bufferevents now make sure to always set one
334  of BEV_EVENT_READING or BEV_EVENT_WRITING when invoking an event
335  callback.
336
337  Calling bufferevent_set_timeouts(bev, NULL, NULL) now removes the
338  timeouts from socket and ssl bufferevents correctly.
339
340  You can find the priority at which a bufferevent runs with
341  bufferevent_get_priority().
342
343  The function bufferevent_get_token_bucket_cfg() can retrieve the
344  rate-limit settings for a bufferevent; bufferevent_getwatermark() can
345  return a bufferevent's current watermark settings.
346
347  You can manually trigger a bufferevent's callbacks via
348  bufferevent_trigger() and bufferevent_trigger_event().
349
350  Also you can manually increment/decrement reference for bufferevent with
351  bufferevent_incref()/bufferevent_decref(), it is useful in situations where a
352  user may reference the bufferevent somewhere else.
353
354  Now bufferevent_openssl supports "dirty" shutdown (when the peer closes the
355  TCP connection before closing the SSL channel), see
356  bufferevent_openssl_get_allow_dirty_shutdown() and
357  bufferevent_openssl_set_allow_dirty_shutdown().
358
359  And also libevent supports openssl 1.1.
360
3611.7. New functions and features: evdns
362
363  The previous evdns interface used an "open a test UDP socket" trick in
364  order to detect IPv6 support.  This was a hack, since it would
365  sometimes badly confuse people's firewall software, even though no
366  packets were sent.  The current evdns interface-detection code uses
367  the appropriate OS functions to see which interfaces are configured.
368
369  The evdns_base_new() function now has multiple possible values for its
370  second (flags) argument.  Using 1 and 0 have their old meanings, though the
371  1 flag now has a symbolic name of EVDNS_BASE_INITIALIZE_NAMESERVERS.
372  A second flag is now supported too: the EVDNS_BASE_DISABLE_WHEN_INACTIVE
373  flag, which tells the evdns_base that it should not prevent Libevent from
374  exiting while it has no DNS requests in progress.
375
376  There is a new evdns_base_clear_host_addresses() function to remove
377  all the /etc/hosts addresses registered with an evdns instance.
378
379  Also there is evdns_base_get_nameserver_addr() for retrieve the address of
380  the 'idx'th configured nameserver.
381
3821.8. New functions and features: evconnlistener
383
384  Libevent 2.1 adds the following evconnlistener flags:
385
386    LEV_OPT_DEFERRED_ACCEPT -- Tells the OS that it doesn't need to
387    report sockets as having arrived until the initiator has sent some
388    data too.  This can greatly improve performance with protocols like
389    HTTP where the client always speaks first.  On operating systems
390    that don't support this functionality, this option has no effect.
391
392    LEV_OPT_REUSEABLE_PORT -- Indicates that we ask to allow multiple servers
393    to bind to the same port if they each set the option Ionly on Linux and
394    >=3.9)
395
396    LEV_OPT_DISABLED -- Creates an evconnlistener in the disabled (not
397    listening) state.
398
399  Libevent 2.1 changes the behavior of the LEV_OPT_CLOSE_ON_EXEC
400  flag.  Previously, it would apply to the listener sockets, but not to
401  the accepted sockets themselves.  That's almost never what you want.
402  Now, it applies both to the listener and the accepted sockets.
403
4041.9. New functions and features: evhttp
405
406  **********************************************************************
407  NOTE: The evhttp module will eventually be deprecated in favor of Mark
408  Ellzey's libevhtp library.  Don't worry -- this won't happen until
409  libevhtp provides every feature that evhttp does, and provides a
410  compatible interface that applications can use to migrate.
411  **********************************************************************
412
413  Previously, you could only set evhttp timeouts in increments of one
414  second.  Now, you can use evhttp_set_timeout_tv() and
415  evhttp_connection_set_timeout_tv() to configure
416  microsecond-granularity timeouts.
417
418  Also there is evhttp_connection_set_initial_retry_tv() to change initial
419  retry timeout.
420
421  There are a new pair of functions: evhttp_set_bevcb() and
422  evhttp_connection_base_bufferevent_new(), that you can use to
423  configure which bufferevents will be used for incoming and outgoing
424  http connections respectively.  These functions, combined with SSL
425  bufferevents, should enable HTTPS support.
426
427  There's a new evhttp_foreach_bound_socket() function to iterate over
428  every listener on an evhttp object.
429
430  Whitespace between lines in headers is now folded into a single space;
431  whitespace at the end of a header is now removed.
432
433  The socket errno value is now preserved when invoking an http error
434  callback.
435
436  There's a new kind of request callback for errors; you can set it with
437  evhttp_request_set_error_cb(). It gets called when there's a request error,
438  and actually reports the error code and lets you figure out which request
439  failed.
440
441  You can navigate from an evhttp_connection back to its evhttp with the
442  new evhttp_connection_get_server() function.
443
444  You can override the default HTTP Content-Type with the new
445  evhttp_set_default_content_type() function
446
447  There's a new evhttp_connection_get_addr() API to return the peer
448  address of an evhttp_connection.
449
450  The new evhttp_send_reply_chunk_with_cb() is a variant of
451  evhttp_send_reply_chunk() with a callback to be invoked when the
452  chunk is sent.
453
454  The evhttp_request_set_header_cb() facility adds a callback to be
455  invoked while parsing headers.
456
457  The evhttp_request_set_on_complete_cb() facility adds a callback to be
458  invoked on request completion.
459
460  You can add linger-close for http server by passing
461  EVHTTP_SERVER_LINGERING_CLOSE to evhttp_set_flags(), with this flag server
462  read all the clients body, and only after this respond with an error if the
463  clients body exceed max_body_size (since some clients cannot read response
464  otherwise).
465
466  The evhttp_connection_set_family() can bypass family hint to evdns.
467
468  There are some flags available for connections, which can be installed with
469  evhttp_connection_set_flags():
470  - EVHTTP_CON_REUSE_CONNECTED_ADDR -- reuse connection address on retry (avoid
471    extra DNS request).
472  - EVHTTP_CON_READ_ON_WRITE_ERROR - try read error, since server may already
473    close the connection.
474
475  The evhttp_connection_free_on_completion() can be used to tell libevent to
476  free the connection object after the last request has completed or failed.
477
478  There is evhttp_request_get_response_code_line() if
479  evhttp_request_get_response_code() is not enough for you.
480
481  There are *evhttp_uri_parse_with_flags() that accepts
482  EVHTTP_URI_NONCONFORMANT to tolerate URIs that do not conform to RFC3986.
483  The evhttp_uri_set_flags() can changes the flags on URI.
484
4851.10. New functions and features: evutil
486
487  There's a function "evutil_secure_rng_set_urandom_device_file()" that
488  you can use to override the default file that Libevent uses to seed
489  its (sort-of) secure RNG.
490
491  The evutil_date_rfc1123() returns date in RFC1123
492
493  There are new API to work with monotonic timer -- monotonic time is
494  guaranteed never to run in reverse, but is not necessarily epoch-based. Use
495  it to make reliable measurements of elapsed time between events even when the
496  system time may be changed:
497  - evutil_monotonic_timer_new()/evutil_monotonic_timer_free()
498  - evutil_configure_monotonic_time()
499  - evutil_gettime_monotonic()
500
501  Use evutil_make_listen_socket_reuseable_port() to set SO_REUSEPORT (linux >=
502  3.9)
503
504  The evutil_make_tcp_listen_socket_deferred() can make a tcp listener socket
505  defer accept()s until there is data to read (TCP_DEFER_ACCEPT).
506
5072. Cross-platform performance improvements
508
5092.1. Better data structures
510
511  We replaced several users of the sys/queue.h "TAILQ" data structure
512  with the "LIST" data structure.  Because this data type doesn't
513  require FIFO access, it requires fewer pointer checks and
514  manipulations to keep it in line.
515
516  All previous versions of Libevent have kept every pending (added)
517  event in an "eventqueue" data structure.  Starting in Libevent 2.0,
518  however, this structure became redundant: every pending timeout event
519  is stored in the timeout heap or in one of the common_timeout queues,
520  and every pending fd or signal event is stored in an evmap.  Libevent
521  2.1 removes this data structure, and thereby saves all of the code
522  that we'd been using to keep it updated.
523
5242.2. Faster activations and timeouts
525
526  It's a common pattern in older code to use event_base_once() with a
527  0-second timeout to ensure that a callback will get run 'as soon as
528  possible' in the current iteration of the Libevent loop.  We optimize
529  this case by calling event_active() directly, and bypassing the
530  timeout pool.  (People who are using this pattern should also consider
531  using event_active() themselves.)
532
533  Libevent 2.0 would wake up a polling event loop whenever the first
534  timeout in the event loop was adjusted--whether it had become earlier
535  or later.  We now only notify the event loop when a change causes the
536  expiration time to become _sooner_ than it would have been otherwise.
537
538  The timeout heap code is now optimized to perform fewer comparisons
539  and shifts when changing or removing a timeout.
540
541  Instead of checking for a wall-clock time jump every time we call
542  clock_gettime(), we now check only every 5 seconds.  This should save
543  a huge number of gettimeofday() calls.
544
5452.3. Microoptimizations
546
547  Internal event list maintainance no longer use the antipattern where
548  we have one function with multiple totally independent behaviors
549  depending on an argument:
550      #define OP1 1
551      #define OP2 2
552      #define OP3 3
553      void func(int operation, struct event *ev) {
554        switch (op) {
555          ...
556        }
557      }
558  Instead, these functions are now split into separate functions for
559  each operation:
560      void func_op1(struct event *ev) { ... }
561      void func_op2(struct event *ev) { ... }
562      void func_op3(struct event *ev) { ... }
563
564  This produces better code generation and inlining decisions on some
565  compilers, and makes the code easier to read and check.
566
5672.4. Evbuffer performance improvements
568
569  The EVBUFFER_EOL_CRLF line-ending type is now much faster, thanks to
570  smart optimizations.
571
5722.5. HTTP performance improvements
573
574   o Performance tweak to evhttp_parse_request_line. (aee1a97 Mark Ellzey)
575   o Add missing break to evhttp_parse_request_line (0fcc536)
576
5772.6. Coarse timers by default on Linux
578
579  Due to limitations of the epoll interface, Libevent programs using epoll
580  have not previously been able to wait for timeouts with accuracy smaller
581  than 1 millisecond.  But Libevent had been using CLOCK_MONOTONIC for
582  timekeeping on Linux, which is needlessly expensive: CLOCK_MONOTONIC_COARSE
583  has approximately the resolution corresponding to epoll, and is much faster
584  to invoke than CLOCK_MONOTONIC.
585
586  To disable coarse timers, and get a more plausible precision, use the
587  new EVENT_BASE_FLAG_PRECISE_TIMER flag when setting up your event base.
588
5893. Backend/OS-specific improvements
590
5913.1. Linux-specific improvements
592
593  The logic for deciding which arguements to use with epoll_ctl() is now
594  a table-driven lookup, rather than the previous pile of cascading
595  branches.  This should minimize epoll_ctl() calls and make the epoll
596  code run a little faster on change-heavy loads.
597
598  Libevent now takes advantage of Linux's support for enhanced APIs
599  (e.g., SOCK_CLOEXEC, SOCK_NONBLOCK, accept4, pipe2) that allow us to
600  simultaneously create a socket, make it nonblocking, and make it
601  close-on-exec.  This should save syscalls throughout our codebase, and
602  avoid race-conditions if an exec() occurs after a socket is socket is
603  created but before we can make it close-on-execute on it.
604
6053.2. Windows-specific improvements
606
607  We now use GetSystemTimeAsFileTime to implement gettimeofday.  It's
608  significantly faster and more accurate than our old ftime()-based approach.
609
6103.3. Improvements in the solaris evport backend.
611
612  The evport backend has been updated to use many of the infrastructure
613  improvements from Libevent 2.0.  Notably, it keeps track of per-fd
614  information using the evmap infrastructure, and removes a number of
615  linear scans over recently-added events.  This last change makes it
616  efficient to receive many more events per evport_getn() call, thereby
617  reducing evport overhead in general.
618
6193.4. OSX backend improvements
620
621  The OSX select backend doesn't like to have more than a certain number
622  of fds set unless an "unlimited select" option has been set.
623  Therefore, we now set it.
624
6253.5. Monotonic clocks on even more platforms
626
627  Libevent previously used a monotonic clock for its internal timekeeping
628  only on platforms supporting the POSIX clock_gettime() interface. Now,
629  Libevent has support for monotonic clocks on OSX and Windows too, and a
630  fallback implementation for systems without monotonic clocks that will at
631  least keep time running forwards.
632
633  Using monotonic timers makes Libevent more resilient to changes in the
634  system time, as can happen in small amounts due to clock adjustments from
635  NTP, or in large amounts due to users who move their system clocks all over
636  the timeline in order to keep nagware from nagging them.
637
6383.6. Faster cross-thread notification on kqueue
639
640  When a thread other than the one in which the main event loop is
641  running needs to wake the thread running the main event loop, Libevent
642  usually writes to a socketpair in order to force the main event loop
643  to wake up.  On Linux, we've been able to use eventfd() instead.  Now
644  on BSD and OSX systems (any anywhere else that has kqueue with the
645  EVFILT_USER extension), we can use EVFILT_USER to wake up the main
646  thread from kqueue.  This should be a tiny bit faster than the
647  previous approach.
648
6494. Infrastructure improvements
650
6514.1. Faster tests
652
653  I've spent some time to try to make the unit tests run faster in
654  Libevent 2.1.  Nearly all of this was a matter of searching slow tests
655  for unreasonably long timeouts, and cutting them down to reasonably
656  long delays, though on one or two cases I actually had to parallelize
657  an operation or improve an algorithm.
658
659  On my desktop, a full "make verify" run of Libevent 2.0.18-stable
660  requires about 218 seconds.  Libevent 2.1.1-alpha cuts this down to
661  about 78 seconds.
662
663  Faster unit tests are great, since they let programmers test their
664  changes without losing their train of thought.
665
6664.2. Finicky tests are now off-by-default
667
668  The Tinytest unit testing framework now supports optional tests, and
669  Libevent uses them.  By default, Libevent's unit testing framework
670  does not run tests that require a working network, and does not run
671  tests that tend to fail on heavily loaded systems because of timing
672  issues.  To re-enable all tests, run ./test/regress using the "@all"
673  alias.
674
6754.3. Modernized use of autotools
676
677  Our autotools-based build system has been updated to build without
678  warnings on recent autoconf/automake versions.
679
680  Libevent's autotools makefiles are no longer recursive.  This allows
681  make to use the maximum possible parallelism to do the minimally
682  necessary amount of work.  See Peter Miller's "Recursive Make
683  Considered Harmful" at http://miller.emu.id.au/pmiller/books/rmch/ for
684  more information here.
685
686  We now use the "quiet build" option to suppress distracting messages
687  about which commandlines are running.  You can get them back with
688  "make V=1".
689
6904.4. Portability
691
692  Libevent now uses large-file support internally on platforms where it
693  matters.  You shouldn't need to set _LARGEFILE or OFFSET_BITS or
694  anything magic before including the Libevent headers, either, since
695  Libevent now sets the size of ev_off_t to the size of off_t that it
696  received at compile time, not to some (possibly different) size based
697  on current macro definitions when your program is building.
698
699  We now also use the Autoconf AC_USE_SYSTEM_EXTENSIONS mechanism to
700  enable per-system macros needed to enable not-on-by-default features.
701  Unlike the rest of the autoconf macros, we output these to an
702  internal-use-only evconfig-private.h header, since their names need to
703  survive unmangled.  This lets us build correctly on more platforms,
704  and avoid inconsistencies when some files define _GNU_SOURCE and
705  others don't.
706
707  Libevent now tries to detect OpenSSL via pkg-config.
708
7094.5. Standards conformance
710
711  Previous Libevent versions had no consistent convention for internal
712  vs external identifiers, and used identifiers starting with the "_"
713  character throughout the codebase.  That's no good, since the C
714  standard says that identifiers beginning with _ are reserved.  I'm not
715  aware of having any collisions with system identifiers, but it's best
716  to fix these things before they cause trouble.
717
718  We now avoid all use of the _identifiers in the Libevent source code.
719  These changes were made *mainly* through the use of automated scripts,
720  so there shouldn't be any mistakes, but you never know.
721
722  As an exception, the names _EVENT_LOG_DEBUG, _EVENT_LOG_MSG_,
723  _EVENT_LOG_WARN, and _EVENT_LOG_ERR are still exposed in event.h: they
724  are now deprecated, but to support older code, they will need to stay
725  around for a while.  New code should use EVENT_LOG_DEBUG,
726  EVENT_LOG_MSG, EVENT_LOG_WARN, and EVENT_LOG_ERR instead.
727
7284.6. Event and callback refactoring
729
730  As a simplification and optimization to Libevent's "deferred callback"
731  logic (introduced in 2.0 to avoid callback recursion), Libevent now
732  treats all of its deferrable callback types using the same logic it
733  uses for active events.  Now deferred events no longer cause priority
734  inversion, no longer require special code to cancel them, and so on.
735
736  Regular events and deferred callbacks now both descend from an
737  internal light-weight event_callback supertype, and both support
738  priorities and take part in the other anti-priority-inversion
739  mechanisms in Libevent.
740
741  To avoid starvation from callback recursion (which was the reason we
742  introduced "deferred callbacks" in the first place) the implementation
743  now allows an event callback to be scheduled as "active later":
744  instead of running in the current iteration of the event loop, it runs
745  in the next one.
746
7475. Testing
748
749  Libevent's test coverage level is more or less unchanged since before:
750  we still have over 80% line coverage in our tests on Linux, FreeBSD, NetBSD,
751  Windows, OSX.
752  There are some under-tested modules, though: we need to fix those.
753
754  And now we have CI:
755  - https://travis-ci.org/libevent/libevent
756  - https://ci.appveyor.com/project/nmathewson/libevent
757
758  And code coverage:
759  - https://coveralls.io/github/libevent/libevent
760
761  Plus there is vagrant boxes if you what to test it on more OS'es then
762  travis-ci allows, and there is a wrapper (in python) that will parse logs and
763  provide report:
764  - https://github.com/libevent/libevent-extras/blob/master/tools/vagrant-tests.py
765
7666. Contributing
767
768  From now we have contributing guide and checkpatch.sh.
769