mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-09-23 06:24:59 +02:00
469051f650
I started this repository a while ago to work on documentation for Tor's internals. It needs substantial revision, but first, let's get it copied into Tor's repository. These files are copied, "warts and all", from the tor-guts.git repo, commit de1e34259178b09861c0dea319c760fa80d0099a. Part of 31819.
27 lines
1.2 KiB
Markdown
27 lines
1.2 KiB
Markdown
|
|
## Threads in Tor ##
|
|
|
|
Tor is based around a single main thread and one or more worker
|
|
threads. We aim (with middling success) to use worker threads for
|
|
CPU-intensive activities and the main thread for our networking.
|
|
Fortunately (?) we have enough cryptography that moving what we can of the
|
|
cryptographic processes to the workers should achieve good parallelism under most
|
|
loads. Unfortunately, we only have a small fraction of our
|
|
cryptography done in our worker threads right now.
|
|
|
|
Our threads-and-workers abstraction is defined in workqueue.c, which
|
|
combines a work queue with a thread pool, and integrates the
|
|
signalling with libevent. Tor main instance of a work queue is
|
|
instantiated in cpuworker.c. It will probably need some refactoring
|
|
as more types of work are added.
|
|
|
|
On a lower level, we provide locks with tor_mutex_t, conditions with
|
|
tor_cond_t, and thread-local storage with tor_threadlocal_t, all of
|
|
which are specified in compat_threads.h and implemented in an OS-
|
|
specific compat_\*threads.h module.
|
|
|
|
Try to minimize sharing between threads: it is usually best to simply
|
|
make the worker "own" all the data it needs while the work is in
|
|
progress, and to give up ownership when it's complete.
|
|
|