Mike Frysinger wrote:
On Monday 28 January 2008, Wolfgang Denk wrote:
In message 200801280638.59012.vapier@gentoo.org you wrote:
odd ... git-send-email ate the explanatory text ...
The -f option to `ln` should give the same behavior as the -f option to the `rm` command. It is better to do this in one shot so as to avoid race conditions when building in parallel. I build on a quad G5 and without this change, it isn't uncommon for the build to fail when using -j8 due to this small window where the files don't actually exist.
Note that "ln -s -f" will come down to two separate system calls as well:
... unlink(); symlink(); ...
So you don't avoid the race condition; you're just making it a little less likely at the cost of reduced portability.
yes, i know it's much less likely, but that difference on my system has been from 1-in-20 build failures to 1-in-none-so-far-out-of-hundreds. the real fix is to overhaul the u-boot build system, but that'll take quite a bit of time and this change is for all practical purposes, Good Enough. i dont know what portability issues you refer to considering the -f flag is in POSIX and has been supported on all Linux systems since before that (pre-2000). -mike
I don't think there is a race condition at all in the "ln -s -f" case. The race condition exists in the first approach because the shell is allowed to execute the rm and the ln in parallel, while in the "ln -s -f" case the two system calls are sequential in the same thread of execution (inside ln) and therefore happen in a defined order. It is not just that the window is small, there is no window. -Bill
This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users