Previously, we wouldn't decrement read/write buckets because of IOCP
reads and writes until those reads and writes were complete. That's
not so bad on the per-connection front. But for group limits, the
old approach makes us launch a huge amount of reads and writes
whenever the group limit becomes positive, and then decrement the
limit to a hugely negative number as they complete.
With this patch, we decrement our read buckets whenever we launch an
IOCP read or write, based on the maximum that tried to read or
write. Later, when the operations finish, we re-increment the
bucket based on the portion of the request that couldn't finish.
Original message:
Solaris sendfile seems to fail when sending moderately large (<1GB)
files. Not a 32/64 problem, but a buffer problem.
Anyone else ever try this? It is definitely broken in http-server.c.
It seems to be broken in the following way:
When sendfile sends partial data (EAGAIN, would block), "res" is
always -1, rather than the amount sent.
Here's a patch that reads from the "offset" pointer instead to
discover what was sent. This seems to work:
The "min_share" logic, which was designed to prevent piles of
extremely small writes when running up against a group rate limit,
could lead to confusing behavior if you ever set a min_share less
than your burst rate. If that happened, then as soon as your group
rate limit was exhausted, you'd stop reading/writing, and never
start again, since the amount readable/writeable would never
actually hit min_share.
We now cap min_share at the rate per tick.
Found by George Kadianakis
Starting with Lion, Apple decided to deprecate the system openssl. We
can start requiring users to install their own openssl once OS X doesn't
ship with it anymore.
Original mail:
the logic that handles write watermarks in "bio_bufferevent_write"
is not working. It currently doesn't write any data if the high
watermark is *above* the amount of data to write (i.e. when there
is actually enough room available).
- redeclaration of dst_size
- arpa/inet.h requires netinet/in.h first
- don't use a local with the same name as a global - it isn't needed so
remove it
Original post:
This post is in response to a posting last December on a Windows
regression fork failure ([Libevent-users] Re: Libevent 2.0.10-stable
is released by Dongsheng Song). I noticed the question was not
answered and I recently experienced the same error myself when
trying to run the Windows regression tests myself.
I checked the return status from the CreateProcess call and found it
was "file not found". This led me to look at the command-line I was
using which was .\regress in a Visual Studio 2008 command prompt
window. Windows could not find the file because it did not have the
.exe extension on the end. The code that builds the command should
be modified to ensure the extension is present.
When asked to add one side of a pipe, and the other side has been
closed, kqueue on NetBSD will say EBADF; kqueue on FreeBSD will say
EPIPE, and kqueue on OpenBSD will say EPERM. So treat all of these
as EV_READ events, to give the user an opportunity to notice that
the pipe is closed.
Diagnosed by Nicholas Marriott and Dale Rahn; based on a patch by
Nicholas Marriott.
event_base_free(NULL) means "free the current event base".
Previously, it would assert if there was no 'current' base. Now it
just warns and returns.
Reported by Gilad Benjamini
