[gentoo-dev] [PATCH multibuild.eclass] Use portable locking code from Fabian Groffen.

[gentoo-dev] [PATCH multibuild.eclass] Use portable locking code from Fabian Groffen.

[Michał Górny]

The 'userland_*' flags have proven not good enough to determine
the availability of lock helpers. Fabian provided a nice portable
locking code instead.

Fixes: https://bugs.gentoo.org/show_bug.cgi?id=466554
---
 gx86/eclass/multibuild.eclass | 29 +++++++++++++++--------------
 1 file changed, 15 insertions(+), 14 deletions(-)

diff --git a/gx86/eclass/multibuild.eclass b/gx86/eclass/multibuild.eclass
index acfdbbd..819c814 100644
--- a/gx86/eclass/multibuild.eclass
+++ b/gx86/eclass/multibuild.eclass
@@ -251,38 +251,39 @@ multibuild_merge_root() {
 	local src=${1}
 	local dest=${2}
 
-	local lockfile=${T}/multibuild_merge_lock
+	local lockfile=${T}/.multibuild_merge_lock
+	local lockfile_l=${lockfile}.${$}
 	local ret
 
+	# Lock the install tree for merge. The touch+ln method ensures race
+	# condition-free locking with maximum portability.
+	touch "${lockfile_l}" || die
+	until ln "${lockfile_l}" "${lockfile}" &>/dev/null; do
+		sleep 1
+	done
+	rm "${lockfile_l}" || die
+
 	if use userland_BSD; then
-		# Locking is done by 'lockf' which can wrap a command.
 		# 'cp -a -n' is broken:
 		# http://www.freebsd.org/cgi/query-pr.cgi?pr=174489
 		# using tar instead which is universal but terribly slow.
 
 		tar -C "${src}" -f - -c . \
-			| lockf "${lockfile}" tar -x -f - -C "${dest}"
+			| tar -x -f - -C "${dest}"
 		[[ ${PIPESTATUS[*]} == '0 0' ]]
 		ret=${?}
 	elif use userland_GNU; then
-		# GNU has 'flock' which can't wrap commands but can lock
-		# a fd which is good enough for us.
-		# and cp works with '-a -n'.
-
-		local lock_fd
-		redirect_alloc_fd lock_fd "${lockfile}" '>>'
-		flock ${lock_fd}
+		# cp works with '-a -n'.
 
 		cp -a -l -n "${src}"/. "${dest}"/
 		ret=${?}
-
-		# Close the lock file when we are done with it.
-		# Prevents deadlock if we aren't in a subshell.
-		eval "exec ${lock_fd}>&-"
 	else
 		die "Unsupported userland (${USERLAND}), please report."
 	fi
 
+	# Remove the lock.
+	rm "${lockfile}" || die
+
 	if [[ ${ret} -ne 0 ]]; then
 		die "${MULTIBUILD_VARIANT:-(unknown)}: merging image failed."
 	fi
-- 
1.8.2.1

Re: [gentoo-dev] [PATCH multibuild.eclass] Use portable locking code from Fabian Groffen.

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 533 bytes --]

On Wednesday 15 May 2013 15:22:21 Michał Górny wrote:
> The 'userland_*' flags have proven not good enough to determine
> the availability of lock helpers. Fabian provided a nice portable
> locking code instead.
> 
> Fixes: https://bugs.gentoo.org/show_bug.cgi?id=466554
> ---
>  gx86/eclass/multibuild.eclass | 29 +++++++++++++++--------------

this seems more appropriate for portability.eclass than other random places.  
there you can keep flock when it's available, or fall back to manual hacks like 
this.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] [PATCH multibuild.eclass] Use portable locking code from Fabian Groffen.

[Zac Medico]

On 05/23/2013 12:29 PM, Mike Frysinger wrote:
> On Wednesday 15 May 2013 15:22:21 Michał Górny wrote:
>> The 'userland_*' flags have proven not good enough to determine
>> the availability of lock helpers. Fabian provided a nice portable
>> locking code instead.
>>
>> Fixes: https://bugs.gentoo.org/show_bug.cgi?id=466554
>> ---
>>   gx86/eclass/multibuild.eclass | 29 +++++++++++++++--------------
>
> this seems more appropriate for portability.eclass than other random places.
> there you can keep flock when it's available, or fall back to manual hacks like
> this.

It can be tricky find out whether or not the underlying filesystem will 
behave well with flock. For example, maybe it will just fail temporarily 
due to lock exhaustion (ENOLCK), or maybe the filesystem doesn't support 
locking at all (ENOSYS).

Given all of the variables, it may be safest to use hardlink locks in 
any case, since they work reliably on practically any relevant 
filesystem. So if we do end up putting something in portability.eclass, 
maybe hardlink locks are the way to go. Alternatively, we could add some 
locking functions in the next EAPI, and let the package manager handle 
the implementation details.
-- 
Thanks,
Zac