Subject: Re: pkgsrc locking
To: Joachim =?iso-8859-1?Q?K=F6nig?= <him@online.de>
From: Marc Espie <espie@nerim.net>
List: tech-pkg
Date: 06/15/2007 15:32:16
On Thu, Jun 14, 2007 at 12:53:37PM +0200, Joachim König wrote:
> On Wed, Jun 13, 2007 at 09:39:41PM +0200, Joerg Sonnenberger wrote:
> 
> >On[e] problem is that shlock style locking requires to create a file, e.g.
> >it requires to have the WRKDIR present. This is problematic when using
> >clean as part of the build targets.
> If the lock file would be created "parallel" to WRKDIR, e.g. in the same
> parent directory e.g. by calling it ${WRKDIR}.lock it could exist as
> long as required, even surviving a "make cleandir", and would work
> with parallel sandbox builds that nullmount the pkgsrc tree.

In OpenBSD, we solved this by having a variable LOCKDIR that says where
you want to create the locks, and creating them only if it's defined and
non-empty. A very popular settings for LOCKDIR is /tmp, as it's often
mfs-mounted, and unlikely to have issues with... whatever, like NFS.

This may cause collisions if you happen to use an NFS-mounted ports tree
on several architectures, but in that case, we also advise people to not
share their ports WRKDIR in that case. We've got WRKOBJDIR to make it
build stuff elsewhere.

We also had one specific problem, I don't know if you've run into that one,
which is of some ports have dependencies that end up wrapping to a different
version of themselves. This used to be very annoying, we had to take care
not to lock the same stuff twice, until... I figured out I could
record the locks I was already holding in a make variable, and pass it
to every submake.

The relevant code fragment that does this looks like this:

.  for _i in ${_LOCKNAME}
.    if empty(_LOCKS_HELD:M${_i})
_DO_LOCK = \
    lock=${_LOCKNAME}; \
        _LOCKS_HELD="${_LOCKS_HELD} ${_LOCKNAME}"; export _LOCKS_HELD; \
	    ${_SIMPLE_LOCK}
.    endif
.  endfor
_SIMPLE_LOCK = \
	${_LOCK}; trap '{_UNLOCK}' 0 1 2 3 13 15
_SIMPLE_LOCK ?= :
_DO_LOCK ?= :

a casual glance at the netbsd code shows me you have vastly different code,
but if you ever decide to tackle the issue of holding locks for longer,
it is rather simple, once you realize you can pass the list of locks to
submakes.