summaryrefslogtreecommitdiff
path: root/HACKING
diff options
context:
space:
mode:
authorStefan Walter <stefw@src.gnome.org>2007-07-14 17:04:42 +0000
committerStefan Walter <stefw@src.gnome.org>2007-07-14 17:04:42 +0000
commit3633775a2b8ef45fdaec4a17dd4f26d97e5bfec2 (patch)
tree7e31c4b262c107d17995a386e6ac4bd654d33159 /HACKING
parent3541259225ab50b953f3e5cc0a60eddb311ba4f3 (diff)
downloadgnome-keyring-3633775a2b8ef45fdaec4a17dd4f26d97e5bfec2.tar.gz
Move to a cooperative threading model for the daemon, this simplifies a
* common/gkr-async.c: * common/gkr-async.h: * common/gkr-unix-signal.c: * common/gkr-unix-signal.h: * common/gkr-wakeup.c: * common/gkr-wakeup.h: * daemon/gnome-keyring-daemon.c: * daemon/gnome-keyring-daemon.h: * daemon/gnome-keyring-daemon-io.c: * daemon/gnome-keyring-daemon-ops.c: * tests/unit-test-async.c: * tests/unit-test-mainloop-setup.c: * tests/unit-test-private.h: * tests/unit-test-signal.c: * ui/gkr-ask-daemon.c: * ui/gkr-ask-daemon.h: * ui/gkr-ask-request.c: * ui/gkr-ask-request.h: Move to a cooperative threading model for the daemon, this simplifies a lot of code and will make adding in the other parts of the daemon (PKCS#11 and SSH, etc...) far easier. svn path=/trunk/; revision=687
Diffstat (limited to 'HACKING')
-rw-r--r--HACKING21
1 files changed, 18 insertions, 3 deletions
diff --git a/HACKING b/HACKING
index 6cfc18c6..8131e1d2 100644
--- a/HACKING
+++ b/HACKING
@@ -7,9 +7,6 @@ http://bugzilla.gnome.org/enter_bug.cgi?product=gnome-keyring
Gnome Keyring is made up of several distinct parts working on concert with
each other. These parts generally live in different directories:
-cryptoki
- The PKCS#11 provider code
-
daemon
The main daemon startup code and gnome-keyring password protocol operations.
@@ -25,3 +22,21 @@ tests
ui
Prompting the user, asking for passwords.
+
+USE OF THREADS
+
+Gnome Keyring uses threads in a limited manner, as state machines, or execution
+stacks. Only one thread runs at any given time, each thread hands off execution
+to another thread.
+
+The *only* use of threading and/or synchronization primitives should be in:
+
+ common/gkr-async.c
+
+Worker threads are created by using gkr_async_worker_start(). Each worker needs
+to call gkr_async_yield() regularly, to give other threads a chance to run.
+
+If a thread needs perform a blocking syscall, or do something that takes a long
+time (like create a key) it can use the gkr_async_begin_concurrent() and
+gkr_async_end_concurrent() functions. While running 'concurrent' no global
+functions and/or data should be accessed.