| Age | Commit message (Collapse) | Author |
|---|
|
This commit won't build yet -- it just puts everything in a slightly
more logical place.
The reasoning here is that "src/core" will hold the stuff that every (or
nearly every) tor instance will need in order to do onion routing.
Other features (including some necessary ones) will live in
"src/feature". The "src/app" directory will hold the stuff needed
to have Tor be an application you can actually run.
This commit DOES NOT refactor the former contents of src/or into a
logical set of acyclic libraries, or change any code at all. That
will have to come in the future.
We will continue to move things around and split them in the future,
but I hope this lays a reasonable groundwork for doing so.
|
|
|
|
These were necessary long ago to work around a bug in VC6.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* ADD new /src/common/crypto_rand.[ch] module.
* ADD new /src/common/crypto_util.[ch] module (contains the memwipe()
function, since all crypto_* modules need this).
* FIXES part of #24658: https://bugs.torproject.org/24658
|
|
This change makes cpuworker and test_workqueue no longer need to
include event2/event.h. Now workqueue.c needs to include it, but
that is at least somewhat logical here.
|
|
When a relay is collecting internal statistics about how many
create cell requests it has seen of each type, accurately count the
requests from relays that temporarily fall out of the consensus.
(To be extra conservative, we were already ignoring requests from clients
in our counts, and we continue ignoring them here.)
Fixes bug 24910; bugfix on 0.2.4.17-rc.
|
|
some of these ought to have been noticed by the "misspell" tool,
so if anybody is debugging it, here are some bug reports :)
|
|
|
|
|
|
|
|
Now that half the threads are permissive and half are strict, we
need to make sure we have at least two threads, so that we'll
have at least one of each kind.
|
|
Fixes bug 22883.
|
|
|
|
now it looks like the other time we call it
|
|
|
|
Closes ticket 22356
|
|
I'll be using this in the unit tests for consdiffmgr.
|
|
|
|
|
|
Previously we freed the old "keys" object, but leaked the
worker_state_t that we had taken it from.
Fixes bug 20401; bugfix on 0.2.6.3-alpha.
|
|
This commit adds or improves the module-level documenation for:
buffers.c circuitstats.c command.c connection_edge.c control.c
cpuworker.c crypto_curve25519.c crypto_curve25519.h
crypto_ed25519.c crypto_format.c dircollate.c dirserv.c dns.c
dns_structs.h fp_pair.c geoip.c hibernate.c keypin.c ntmain.c
onion.c onion_fast.c onion_ntor.c onion_tap.c periodic.c
protover.c protover.h reasons.c rephist.c replaycache.c
routerlist.c routerparse.c routerset.c statefile.c status.c
tor_main.c workqueue.c
In particular, I've tried to explain (for each documented module)
what each module does, what's in it, what the big idea is, why it
belongs in Tor, and who calls it. In a few cases, I've added TODO
notes about refactoring opportunities.
I've also renamed an argument, and fixed a few DOCDOC comments.
|
|
Only some very ancient distributions don't ship with Libevent 2 anymore,
even the oldest supported Ubuntu LTS version has it. This allows us to
get rid of a lot of compat code.
|
|
|
|
This includes a small refactoring to use a new enum (workqueue_reply_t)
for the return values instead of just ints.
|
|
|
|
|
|
Fixes bug 15245; bugfix on 0.2.6.3-alpha. Thanks to anonym for reporting!
|
|
Also remove the unit test mocks that allowed get_options() to be
NULL; that's an invariant violation for get_options().
|
|
The issue is that we use the cpuworker system with relays only, so if we
start up as a client and transition to being a relay later, we'll be
sad.
This fixes bug 14901; not in any released version of Tor.
|
|
These were suggested by dgoulet, thanks!
|
|
This fixes a bug where we decide to free the circuit because it isn't on
any workqueue anymore, and then the job finishes and the circuit gets
freed again.
Fixes bug #14815, not in any released version of Tor.
|
|
David Goulet finds that when he runs a busy relay for a while with the
latest version of the git code, the number of onionskins handled
slowly dwindles to zero, with total_pending_tasks wedged at its
maximum value.
I conjecture this is because the total_pending_tasks variable isn't
decremented when we successfully cancel a job. Fixed that.
Fixes bug 14741; bugfix not on any released version of tor.
|
|
|
|
|
|
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
Previously I used one queue per worker; now I use one queue for
everyone. The "broadcast" code is gone, replaced with an idempotent
'update' operation.
|
|
The solution I took is to not free a circuit with a pending
uncancellable work item, but rather to set its magic number to a
sentinel value. When we get a work item, we check whether the circuit
has that magic sentinel, and if so, we free it rather than processing
the reply.
|
|
To avoid having diffs turn out too big, I had replaced some unneeded
ifs and fors with if (1), so that the indentation would still work out
right. Now I might as well clean those up.
|
|
|
|
|
|
|
|
Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code. Right?
|
|
|
|
Long ago we supported systems where there was no support for
threads, or where the threading library was broken. We shouldn't
have do that any more: on every OS that matters, threads exist, and
the OS supports running threads across multiple CPUs.
This resolves tickets 9495 and 12439. It's a prerequisite to making
our workqueue code work better, since sensible workqueue
implementations don't split across multiple processes.
|
