summaryrefslogtreecommitdiff
path: root/src/lib/thread
diff options
context:
space:
mode:
Diffstat (limited to 'src/lib/thread')
-rw-r--r--src/lib/thread/lib_thread.md (renamed from src/lib/thread/lib_thread.dox)2
-rw-r--r--src/lib/thread/threading.md26
2 files changed, 26 insertions, 2 deletions
diff --git a/src/lib/thread/lib_thread.dox b/src/lib/thread/lib_thread.md
index 2773aa009d..5870ad790f 100644
--- a/src/lib/thread/lib_thread.dox
+++ b/src/lib/thread/lib_thread.md
@@ -1,4 +1,3 @@
-/**
@dir /lib/thread
@brief lib/thread: Mid-level threading.
@@ -6,4 +5,3 @@ This module contains compatibility and convenience code for multithreading,
except for low-level locks (which are in \refdir{lib/lock} and
workqueue/threadpool code (which belongs in \refdir{lib/evloop}.)
-**/
diff --git a/src/lib/thread/threading.md b/src/lib/thread/threading.md
new file mode 100644
index 0000000000..a1058c97de
--- /dev/null
+++ b/src/lib/thread/threading.md
@@ -0,0 +1,26 @@
+
+@page threading Threading 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's 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 in \refdir{lib/lock}, and
+higher-level locking/threading tools in \refdir{lib/thread}, including
+conditions (tor_cond_t), thread-local storage (tor_threadlocal_t), and more.
+
+
+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.
+