The sendfile() implementation for evbuffer_add_file is potentially more
efficient, but it has a problem: you can only use it to send bytes over
a socket using sendfile(). If you are writing bytes via SSL_send() or
via a filter, or if you need to be able to inspect your buffer, it
doesn't work.
As an easy fix, this patch disables the sendfile-based implementation of
evbuffer_add_file on an evbuffer unless the user sets a new
EVBUFFER_FLAG_DRAINS_TO_FD flag on that evbuffer, indicating that the
evbuffer will not be inspected, but only written out via
evbuffer_write(), evbuffer_write_atmost(), or drained with stuff like
evbuffer_drain() or evbuffer_add_buffer(). This flag is off by
default, except for evbuffers used for output on bufferevent_socket.
In the future, it could be interesting to make a best-effort file
segment implementation that tries to send via sendfile, but mmaps on
demand. That's too much complexity for a stable release series, though.
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.
