| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
Also, try to resolve some doxygen issues. First, define a magic
"This is doxygen!" macro so that we take the correct branch in
various #if/#else/#endifs in order to get the right documentation.
Second, add in a few grouping @{ and @} entries in order to get some
variables and fields to get grouped together.
|
|
This commit is completely mechanical; I used this perl script to make it:
#!/usr/bin/perl -w -i.bak -p
if (/^\s*\#/) {
s/MS_WINDOWS/_WIN32/g;
s/\bWIN32\b/_WIN32/g;
}
|
|
This re-applies f77f9bddb8bf0dd6e9c3e0d94269aa23f459a272 which got
accidentally reverted in 53f535aeb863204470379b2da4631770fa10b13f.
Thanks asn for spotting this.
|
|
This reverts commit 406ae1ba5ad529a4d0e710229dab6ed645d42b50.
|
|
This reverts commit f77f9bddb8bf0dd6e9c3e0d94269aa23f459a272.
|
|
This reverts commit 7920ea55b8d994268d2b07f27316b0f34d8f27e5.
|
|
This reverts commit 9a88c0cd32df53116a6bbb6b961650943755061c.
|
|
This reverts commit aba25a6939a5907d40dbcff7433a8c130ffd12ad.
|
|
This avoids a dangling pointer issue in the 3412 code, and should
fix bug 4599.
|
|
|
|
This version avoids the timeout system entirely, gives a nicer
interface, and lets us manage allocation explicitly.
|
|
|
|
|
|
This is a fancier bug4457 workaround for 0.2.3. In 0.2.2, we could
just tell Libevent "Don't enable locking!" so it wouldn't try to make
the event_base notifiable. But for IOCP, we need a notifiable base.
(Eventually, we'll want a notifiable base for other stuff, like
multithreaded crypto.) So the solution is to try a full-featured
initialization, and then retry with all the options turned off if that
fails.
|
|
Conflicts:
src/common/compat_libevent.c
Resolving conflict by not taking 7363eae13cb8 ("Use the
EVENT_BASE_FLAG_NOLOCK flag to prevent socketpair() invocation"): in
Tor 0.2.3.x, we _do_ sometimes use notifiable event bases.
|
|
|
|
In Tor 0.2.2, we never need the event base to be notifiable, since we
don't call it from other threads. This is a workaround for bug 4457,
which is not actually a Tor bug IMO.
|
|
Also use this new approach in the bufferevents-enabled case.
|
|
|
|
When we're doing filtering ssl bufferevents, we want the rate-limits
to apply to the lowest level of the bufferevent stack, so that we're
actually limiting bytes sent on the network. Otherwise, we'll read
from the network aggressively, and only limit stuff as we process it.
|
|
|
|
|
|
For some inexplicable reason, Coverity departs from its usual
standards of avoiding false positives here, and warns about all
sscanf usage, even when the formatting strings are totally safe.
Addresses CID # 447, 446.
|
|
Conflicts:
src/common/Makefile.am
src/or/control.c
|
|
|
|
Conflicts:
src/common/address.c
src/common/compat_libevent.c
src/common/memarea.c
src/common/util.h
src/or/buffers.c
src/or/circuitbuild.c
src/or/circuituse.c
src/or/connection.c
src/or/directory.c
src/or/networkstatus.c
src/or/or.h
src/or/routerlist.c
|
|
|
|
|
|
|
|
Trivial Conflicts in
src/common/crypto.c
src/or/main.h
src/or/or.h
|
|
About 860 doxygen-less things remain in 0.2.2
|
|
|
|
|
|
|
|
Libevent 2.0 has a "changelist" feature that avoids making redundant
syscalls if we wind up doing a lot of event_add/event_del operations
on the same fd in a row. Unfortunately, due to a weird design
choice in Linux, it doesn't work right with epoll when multiple fds
refer to the same socket (e.g., one is a dup() of the other). We
don't dup() anything we give to Libevent, though, so it is safe for
us to explicitly turn this feature on.
|
|
Doing so could make Libevent call Libevent from inside a Libevent
logging call, which is a recipe for reentrant confusion and
hard-to-debug crashes. This would especially hurt if Libevent
debug-level logging is enabled AND the user has a controller
watching for low-severity log messages.
Fix bug 2190; fix on 0.1.0.2-rc.
|
|
|
|
|
|
The short version is, "where we want to do it, we have nothing real to
chose from and we can't do it easily. Where it's easy to do, we have
no reason to do it yet."
|
|
|
|
|
|
|
|
|
|
This requires the latest Git version of Libevent as of 24 March 2010.
In the future, we'll just say it requires Libevent 2.0.5-alpha or
later.
Since Libevent doesn't yet support hierarchical rate limit groups,
there isn't yet support for tracking relayed-bytes separately when
using the bufferevent system. If a future version does add support
for hierarchical buckets, we can add that back in.
|
|
|
|
|
|
This should make us conflict less with system files named "log.h".
Yes, we shouldn't have been conflicting with those anyway, but some
people's compilers act very oddly.
The actual change was done with one "git mv", by editing
Makefile.am, and running
find . -name '*.[ch]' | xargs perl -i -pe 'if (/^#include.*\Wlog.h/) {s/log.h/torlog.h/; }'
|
