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.
This takes its runtime back up a little again, but not so high as it
was before. It appears to address the heisenbug issues of github
nmathewson/libevent issue #49. So far.
Apparently, now that we have tests for it in main/common_timeout, we
can now see that it sometimes breaks referential integrity somehow.
Since I'd like to get 2.1.1-alpha out the door soon, I'm turning it
off for now.
What was I thinking? The old function could handle heap-to-heap
transitions, and transitions within the same common timeout queue, but
it completely failed to handle heap/queue transitions, or transitions
between timeout queues.
Now, alas, it's complicated. I should look hard at the assembly here
to see if it's actually better than the alternatives.
This function uses a C program to generate its output, and then uses a
Python program to check it for correctness. On systems without
Python, we just make sure that the C program doesn't crash.
It's likely that we should be requiring some particular python version.
This is an alpha, though: I'm sure somebody will tell us which.
