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).
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)
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)
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.
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.
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.)
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.
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.
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.
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.)
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.
