Use lockf rather than flock when taking the cgilock, for better portability.

This kind of change is scary, but this particular lock is very simply
used and so it seems ok to make it even just for better portability to
SunOS. (People still use that?)

1 files changed, 13 insertions, 1 deletions

diff --git a/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn b/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn
index 2913bfb53..aca1ef106 100644
--- a/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn
+++ b/doc/bugs/ikiwiki_cgi_fails_to_build_on_Solaris_due_to_missing_LOCK__95__EX.mdwn
@@ -28,4 +28,16 @@ to read
     if (lockfd != -1 && lockf(lockfd, F_LOCK,0) == 0) {
 
 
-in IkiWiki/Wrapper.pm  lets it compile, according to http://man-wiki.net/index.php/3:lockf "On  Linux, this call is just an interface for fcntl(2)"  does this seem like a sensible fix?
+in IkiWiki/Wrapper.pm  lets it compile, according to
+http://man-wiki.net/index.php/3:lockf "On  Linux, this call is just an
+interface for fcntl(2)"  does this seem like a sensible fix?a
+
+> Don't see why not. flock was used only because it's being used
+> in the same file for testing some other locks.
+> 
+> While lockf's fcntl locks are not inherited across a fork,
+> that doesn't matter for this lock, which is only used to
+> prevent more than one ikiwiki perl process being run at a time.
+> Nor is there any need to be compatible with some other user of this
+> lock; it's only checked in one place. [[applied|done]]
+> --[[Joey]]