Merge branch '21_nonrecursive'

Make all tests that hit the network disabled by default

To run only these tests, run test/regress with @live_net.  To run all
tests, run test/regress with @all.

Update to latest tinytest (911b4f0349377)

Make test_evutil_monotonic a little more tolerant

Make th_base_lock nonrecursive

This is necessary for making some thread libraries work with
event.c, and might get better performance with others.

The biggest change required here was that we needed to make some
internal code that had previously called event_add and event_del
call the nolock variants.

Merge branch 'master' of ssh://github.com/libevent/libevent

remove a now-unused var in thread_deferred_cb_skew test

Merge branch '21_event_callback_v3'

Avoid a resource leak on error in http client benchmark

Simplify and correct evutil_open_closeonexec_

The original code needlessly called open in its two- or three-
argument format depending on the O_CREAT flag; this should not be
needed.

The code also leaked an fd if fcntl() failed.

Reported by Dave Hart.

Avoid giving a spurious warning when timerfd support is unavailable

We forgot to do the obligatory "Check if there is no syscall there"
dance when calling timerfd_create().

(Commit message by Nick)

Make the Makefile.nmake warning slightly less dire

Add evutil_time.obj to Makefile.nmake

Merge remote-tracking branch 'origin/patches-2.0'

Merge pull request #57 from rosslagerwall/memleak

Fix a couple of memory leaks (found with Valgrind).

Fix a couple of memory leaks (found with Valgrind).

Merge pull request #56 from rosslagerwall/fix-comment

Fix a comment in test-fdleak after 077c7e949.

Fix a comment in test-fdleak after 077c7e949.

Merge remote-tracking branch 'origin/patches-2.0'

Correctly check for arc4random_buf

Apparently it's necssary to do an explicit comparison with NULL here.
This also gets rid of a compile warning

Merge remote-tracking branch 'origin/patches-2.0'

Conflicts:
evutil_rand.c

Had conflicts with _EVENT_ -> EVENT__ change.

check for arc4random_buf at runtime, on OS X

(Tweaked by nickm: Fix up the arcr4andom_buf OSX hack so that the
fallback case isn't compiled into the code when we have
arc4random_buf() and we are not on OSX.  Also add a comment
explaining what's up.)

Merge pull request #54 from rosslagerwall/configure-dup

Remove unnecessary code in configure.in.

Make it more clear that NOLOCK means "I promise, no multithreading"

Add caveat to docs about bufferevent_free() with data in outbuf

Based on libevent-users thread wtih Alexander Klauer

Be more clear that LEV_OPT_DEFERRED_ACCEPT has tricky prereqs

Remove unnecessary code in configure.in.

Add an event_base_loopcontinue() to tell libevent to rescan right away

Restore our priority-inversion-prevention code with deferreds

Back when deferred_cb stuff had its own queue, the queue was always
executed, but we never ran more than 16 callbacks per iteration.
That made for two problems:

1: Because deferred_cb stuff would always run, and had no priority,
it could cause priority inversion.

2: It doesn't respect the max_dispatch_interval code.

Then, when I refactored deferred_cb to be a special case of
event_callback, that solved the above issues, but made for two more
issues:

3: Because deferred_cb stuff would always get the default priority,
it could could low-priority bufferevents to get too much priority.

4: With code like bufferevent_pair, it's easy to get into a
situation where two deferreds keep adding one another, preventing
the event loop from ever actually scanning for more events.

This commit fixes the above by giving deferreds a better notion of
priorities, and by limiting the number of deferreds that can be
added to the _current_ loop iteration's active queues.  (Extra
deferreds are put into the active_later state.)

That isn't an all-purpose priority inversion solution, of course: for
that, you may need to mess around with max_dispatch_interval.

Give event_base_process_active a single exit path

Make event_base_getnpriorities work with old "implicit base" code

Add a bufferevent_get_priority() function

New event_get_priority() function to return an event's priority

Replace more deferred_cb names with event_callback

Replace deferred_cbs with event_callback-based implementation.

event_base_assert_ok: check value of event_active_count for correctness

Add "active later" event_callbacks to supersede deferred

An event or event callback can now be in an additional state: "active
later".  When an event is in this state, it will become active the
next time we run through the event loop.  This lets us do what we
wanted to with deferred callbacks: make a type of active thing that
avoids infinite circular regress in a way that starves other events or
exhausts the stack.  It improves on deferred callbacks by respecting
priorities, and by having a non-kludgy way to avoid event starvation.

Remove the unused bits from EVLIST_ALL

Refactor the callback part of an event into its own event_callback type

This shouldn't have any visible effect, but it's necessary or
advisible for a few changes and cleanups I would like to make,
including:
   * Replacing the deferred queue with a type that works more as if it
     were an event.
   * Introducing a useful "activate this on the next round through the
     event loop" state for events and deferreds.
   * Adding an "on until further notice" status for events, to allow a
     saner win32-hybrid approach.
   * Eventually, making all user callbacks first-class things with
     event-like semantics.

Merge remote-tracking branch 'origin/patches-2.0'

Bump version to 2.0.19-stable-dev

Increment version to 2.0.19-stable

Merge remote-tracking branch 'github/patches-2.0'

Conflicts:
test/regress.c

Oops; fix the *right* windows compile issue

Fix win32 build issues: sleep, pid_t

Merge remote-tracking branch 'origin/patches-2.0'

Conflicts:
ChangeLog
README
evdns.c
sample/dns-example.c

Start changelog for 2.0.19-stable

Fix evdns build with threads disabled

The last evdns change apparently broke it, by using a "base"
variable that we were only declaring with threads turned on.

When retransmitting a timed-out DNS request, pick a fresh nameserver.

Otherwise, requests initially sent to a failing nameserver would
stay there indefinitely, even if other nameservers would work.

Fix for sourceforge bug 3518439

Make some evdns.c debug logs more verbose

dns-example.c can now take a resolv.conf file on the commandline

Correctly handle running on a system where accept4 doesn't work.

Previously, we treated EINVAL as the only errno that indicated a
broken accept4.  But EINVAL only appears when one of the SOCK_*
options isn't supported.  If the accept4 syscall itself isn't there,
we'll get an ENOSYS.

Reported by Azat Khuzhin.

Merge branch '21_robust_monotonic'

Merge remote-tracking branch 'origin/patches-2.0'

Conflicts:
event.c

Merge remote-tracking branch 'github/20_active_prio_inv' into patches-2.0

Merge remote-tracking branch 'origin/patches-2.0'

Conflicts:
bufferevent_openssl.c

Work-around a stupid gcov-breaking bug in OSX 10.6

This only affects the unit tests.

Fix found at http://rachelbythebay.com/w/2011/07/12/forkcrash/

(Backport from 2.1)

Fixed potential double-readcb execution with openssl bufferevents.

the function do_read() will call SSL_read(), and if successful, will
call _bufferevent_run_readcb() before returning to consider_reading().

consider_reading() will then check SSL_pending() to make sure all
pending data has also been read. If it does not, do_read() is called
again.

The issue with this is the possibility that the function that is
executed by _bufferevent_run_readcb() called
bufferevent_disable(ssl_bev, EV_READ) before the second do_read(); In
this case, the users read callback is executed a second time. This is
potentially bad for applications that expect the bufferevent to stay
disabled until further notice. (this is why running openssl bufferevents
without DEFER_CALLBACKS has always been troublesome).

If a higher-priority event becomes active, don't continue running events of the current priority.

Bug found by Ralph Castain.

Generate event-config.h with a single sed script

This approach should make the creation of the file more atomic, to
fix a bug reported by Dinh.

This patch has one change from Zack's original version: it avoids
$<, since Dave Hart tells me he thinks that's not so portable.

(commit message by nickm)

Merge remote-tracking branch 'origin/patches-2.0'

Generate event-config.h with a single sed script

This approach should make the creation of the file more atomic, to
fix a bug reported by Dinh.

This patch has one change from Zack's original version: it avoids
$<, since Dave Hart tells me he thinks that's not so portable.

(commit message by nickm)

When PRECISE_TIMERS is set with epoll, use timerfd for microsecond precision

The epoll interface ordinarily gives us one-millisecond
precision, so on Linux it makes perfect sense to use the
CLOCK_MONOTONIC_COARSE timer.  But when the user has set the new
PRECISE_TIMER flag for an event_base (either by the
EVENT_BASE_FLAG_PRECISE_TIMER flag, or by the EVENT_PRECISE_TIMER
environment variable), they presumably want finer granularity.

On not-too-old Linuxes, we can achieve this using the Timerfd
mechanism, which accepts nanosecond granularity and understands
posix clocks.  It's a little more expensive than just calling
epoll_wait(), so we won't do it by default.

Improve the monotonic-time unit test: make it check the step size

Simple unit tests for monotonic timers

Implement fast/precise monotonic clocks on Windows

This uses code from libutp, which was released under the MIT
license; see evutil_time.c and LICENSE changes.

Add EVENT_PRECISE_TIMER environment var for selecting precise-but-slow timer

Refactor monotonic timer handling into a new type and set of functions; add a gettimeofday-based ratcheting implementation

Now, event.c can always assume that we have a monotonic timer; this
makes event.c easier to write.

Split out time-related prototypes into time-internal.h

Split out time-related evutil functions into a new evutil_time.c

Split long lists in Makefile.am into one-item-per-line

Shave 700 msec off the persistent_timeout_jump test

Merge remote-tracking branch 'origin/patches-2.0'

Merge branch '20_periodic_event_overload_v2' into patches-2.0

If time has jumped so we'd reschedule a periodic event in the past, schedule it for the future instead

Fixes an issue reported on libevent-users in the thread "a dead
looping bug when changing system time backward". Previously, if time
jumped forward 1 hour[*] and we had a one-second periodic timer event,
that event would get invoked 3600 times.  That's almost certainly not
what anybody wants.

In a future version of Libevent, we should expose the amount of time
that the callbac kwould have been invoked somehow.

[*] Forward time jumps can happen with nonmonotonic clocks, or with
clocks that jump on suspend/resume.  It can also happen from
Libevent's point of view if the user exits from event_base_loop() and
doesn't call it again for a while.

Refactor event_persist_closure: raise and extract some common logic

Merge remote-tracking branch 'origin/patches-2.0'

Merge pull request #52 from ghazel/20_evdns_probe

cancel the probe request when the server is freed, and ignore cancelled probe callbacks

remove redundant DNS_ERR_CANCEL check, move comment

cancel the probe request when the server is freed, and ignore cancelled probe callbacks

Note that make_base_notifiable should not be necessary

Merge branch '21_choose_monotonic'

Implement a GetTickCount-based monotonic timer for Windows

On Linux, use CLOCK_MONOTONIC_COARSE by default

You can make it use CLOCK_MONOTONIC again by setting the
EVENT_BASE_FLAG_PRECISE_TIMER flag in the event_config.

EVENT_BASE_FLAG_PRECISE_TIMER indicates we want fine timer precision

There are a bunch of backends that can give us a reasonably good
monotonic timer quickly, or a very precise monotonic timer less
quickly.  For example, Linux has CLOCK_MONOTONIC_COARSE (1msec
precision), which is over twice as fast as CLOCK_MONOTONIC.  Since
epoll only lets you wait with 1msec precision,
CLOCK_MONOTONIC_COARSE is a clear win.

On Windows, you've got GetTickCount{,64}() which is fast, and
QueryPerformanceCounter, which is precise but slow.

Note that even in the cases where the underlying timer claims to
have nanosecond resolution, we're still not exposing that via
Libevent.

Note also that "Precision" isn't the same as "Resolution" or
"Accuracy".  A timer's precision is the smallest change that the
clock will register; a timer's resolution is the fineness of its
underlying representation; a timer's accuracy is how much it drifts
with respect to "Real Time", whatever that means.  (Terms and
definitions from PEP 418.)

Move use_monotonic and friends into event_base

The use_monotonic field used to be a static field set up at library
setup.  Unfortunately, this makes it hard to give the user a way to
make speed/accuracy tradeoffs about time.  Moving it into event_base
should let the clock implementation become configurable.

Work-around a stupid gcov-breaking bug in OSX 10.6

This only affects the unit tests.

Fix found at http://rachelbythebay.com/w/2011/07/12/forkcrash/

Replace pipe-based notification with EVFILT_USER where possible

Sufficiently recent kqueue implementations have an EVFILT_USER filter
that we can use to wake up an event base from another thread.  When
it's supported, we now use this mechanism rather than our old
(pipe-based) mechanism.  This should save some time and complications
on newer OSX and freebsds.

Merge remote-tracking branch 'github/21_mach_time'

Do not track use_monotonic field when is no monotonic clock

Use mach_absolute_time() for monotonic clock support on OSX.

Merge pull request #50 from rosslagerwall/simplify-test

Simplify test.sh code significantly.

Merge branch '21_weakrand'

Tweak the new evutil_weakrand_() code

Make its state actually get seeded.

Document it more thoroughly.

Turn its state into a structure.

Fix a bug in evutil_weakrand_range_() where it could return the top of
the range.

Change its return type to ev_int32_t.

Add a quick unit test to make sure that the value of
evutil_weakrand_range_() is in range.

Change evutil_weakrand_() to avoid platform random()

This change allows us to avoid perturbing the platform's random(), and
to avoid hitting locks on random() in the platform's libc.

evutil_weakrand_() is, well, weak, so we choose here an algorithm that
favors speed over a number of other possibly desirable properties.
We're using a linear congruential generator, and taking our parameters
from those shared by the OpenBSD random() implementation, and
Glibc's fastest random() implementation.

The low bits of a LCG of modulus 2^32 are (notoriously) less random
than the higher bits.  So to generate a random value in a range, using
the % operator is no good; we ought to divide.  We add an
evutil_weakrand_range_() function to do that.

This code also changes the interface of evutil_weakrand_() so that it
now manipulates an explicit seed, rather than having the seed in a
static variable.  This change enables us to use existing locks to
achieve thread-safety, rather than having to rely on an additional lock.

(Patch by Nicholas Marriott; commit message by Nick Mathewson.)

Simplify test.sh code significantly.

Also make it easier to add new tests/backends.

Increment the version to 2.1.1-alpha-dev

Merge remote-tracking branch 'origin/patches-2.0'

Backport: provide EVENT_LOG_* names, and deprecate _EVENT_LOG_*

This is a partial backport of cb9da0bf and a backport of c9635349.

Because C doesn't like us to declare identifiers starting with an
underscore, Libevent 2.1 has renamed every such identifier.  The
only change that affects a public API is that the _EVENT_LOG_*
macros have been renamed to start with EVENT_LOG instead.  The old
names are still present, but deprecated.

I'm doing this backport because it represents the deprecation of a
Libevent 2.0 interface, and folks should have the opportunity to
write code that isn't deprecated and works with both 2.0 and 2.1.

Merge remote-tracking branch 'origin/patches-2.0'