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?)
master
Joey Hess 2011-08-24 17:35:53 -04:00
parent bb1f713f8d
commit c8f7dcbc31
3 changed files with 16 additions and 2 deletions

View File

@ -95,7 +95,7 @@ EOF
# IKIWIKI_CGILOCK_FD so unlockwiki can close it.
$pre_exec=<<"EOF";
lockfd=open("$config{wikistatedir}/cgilock", O_CREAT | O_RDWR, 0666);
if (lockfd != -1 && flock(lockfd, LOCK_EX) == 0) {
if (lockfd != -1 && lockf(lockfd, F_LOCK, 0) == 0) {
char *fd_s=malloc(8);
sprintf(fd_s, "%i", lockfd);
setenv("IKIWIKI_CGILOCK_FD", fd_s, 1);

2
debian/changelog vendored
View File

@ -18,6 +18,8 @@ ikiwiki (3.20110716) UNRELEASED; urgency=low
before Image::Magick.
* Add unminified jquery js and css files to source.
* Update to jquery 1.6.2, and jquery-ui 1.8.14.
* Use lockf rather than flock when taking the cgilock, for better
portability.
-- Joey Hess <joeyh@debian.org> Tue, 19 Jul 2011 11:22:52 -0400

View File

@ -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]]