Some hosts require you to define certain options to get a large off_t
instead of a small one, to get useful ftell and fseek calls instead of
ones that can only support 2GB files, and so on. This patch makes
Libevent support those platforms by:
* Defining the right options when we build, and
* Changing our API so that it does not depend on the platform's
definition of off_t.
Based on discusion with Michael Herf
Using --enable-gcc-hardening enables some additional safety features
that gcc makes available such as stack smashing protection using
canaries and ASLR.
This commit is based on a patch for Tor:
(git commit 04fa935e02270bc90aca0f1c652d31c7a872175b by Jacob Appelbaum)
Copyright (c) 2007-2011, The Tor Project, Inc.
This commit is based on a patch for Tor
(git commit ca60a6ce3f4786626ac455ec1b798b2e8304635c by Peter
Palfrader), Copyright (c) 2007-2011, The Tor Project, Inc.
(Originally, it added --enable-gcc-warnings-advisory as in Tor; Nick
changed that.)
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.
Since we're computing the time after each callback, we might as well
update the time cache (if we're using it) and use monotonic time (if
we've got that).
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:
