aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorJoey Hess <joey@kitenet.net>2012-01-17 23:26:55 -0400
committerJoey Hess <joey@kitenet.net>2012-01-17 23:26:55 -0400
commit17c2bf17783b929f57c6ad01324c14fb5185c493 (patch)
tree0c4791622ecfe4d6973ed4c8f71bf786a28a60cd
parent42b06a462f5e6271b3df20051aa41cb59f416f3c (diff)
downloadikiwiki-17c2bf17783b929f57c6ad01324c14fb5185c493.tar
ikiwiki-17c2bf17783b929f57c6ad01324c14fb5185c493.tar.gz
response
-rw-r--r--doc/bugs/ikiwiki_overzealously_honours_locks_when_asked_for_forms.mdwn33
1 files changed, 33 insertions, 0 deletions
diff --git a/doc/bugs/ikiwiki_overzealously_honours_locks_when_asked_for_forms.mdwn b/doc/bugs/ikiwiki_overzealously_honours_locks_when_asked_for_forms.mdwn
index 05b4a453c..1e74fe8db 100644
--- a/doc/bugs/ikiwiki_overzealously_honours_locks_when_asked_for_forms.mdwn
+++ b/doc/bugs/ikiwiki_overzealously_honours_locks_when_asked_for_forms.mdwn
@@ -1 +1,34 @@
When an `ikiwiki` instance is holding a lock, a web user clicking on "add comment" (for example) will have to wait for the lock to be released. However, all they are then presented with is a web form. Perhaps CGI requests that are read-only (such as generating a comment form, or perhaps certain types of edits) should ignore locks? Of course, I'd understand that the submission would need to wait for a lock. — [[Jon]]
+
+> Ikiwiki has what I think of as the Big Wiki Lock (remembering the "Big
+> Kernel Lock"). It takes the exclusive lock before loading any state,
+> to ensure that any changes to that state are made safely.
+>
+> A few CGI actions that don't need that info loaded do avoid taking the
+> lock.
+>
+> In the case of showing the comment form, the comments
+> plugin needs CGI session information to be loaded, so it can check if
+> the user is logged in, and so it can add XSRF prevention tokens based on
+> the session ID. (Actually, it might be possible to rely on
+> `CGI::Session`'s own locking of the sessions file, and have a hook that
+> runs with a session but before the indexdb is loaded.)
+>
+> But, the comment form also needs to load the indexdb, in order to call
+> `check_canedit`, which matches a pagespec, which can need to look things
+> up in the indexdb. (Though the pagespecs that can do that are unlikely
+> to be relevant when posting a comment.)
+>
+> I've thought about trying to get rid of the Big Wiki Lock from time to
+> time. It's difficult though; if two ikiwikis are both making changes
+> to the stored state, it's hard to see a way to reconcile them. (There
+> could be a daemon that all changes are fed thru using a protocol, but
+> that's really complicated, and it'd almost be better to have a single
+> daemon that just runs ikiwiki; a major architectural change.)
+>
+> One way that *almost* seems it could work is to have a entry path
+> that loads everything read-only, without a lock. And then in read-only
+> mode, `saveindex` would be an error to run. However, both the commenting
+> code and the page edit code currently have the same entry path for
+> drawing the form as is used for handling the posted form, so they would
+> need to be adapted to separate that into two code paths. --[[Joey]]