35 lines
2.2 KiB
Markdown
35 lines
2.2 KiB
Markdown
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]]
|