 |
lua-l archive |
|
|
||
|
The algorithm uses a symlink-based lockfile on POSIX (I have to make up a more descriptive name than lock_dir, as the lock can be used to as an exclusive lock to any resource). I think mkstemp and symlink are supposed to be atomic, so where is the race condition? See http://flinflon.brandonu.ca/Dueck/1997/62306/UNIX/shlock.html for a high-level description of a similar algorithm, and http://ftp.df.lth.se/pub/NetBSD/NetBSD-current/src/usr.bin/shlock/shlock.c for a NetBSD implementation of shlock. Lockfiles are a solution that works for both intra and interprocess locks.
If the lock is taken lock_dir returns an error, how to wait until trying again is up to the user. The ideal way would be to have change notification, but this is very system-specific, so unfortunately busy waiting is the easier way...
Obviously I am not married to this solution, so if you have a suggestion on how to implement exclusive locks that works both inside the same process (even in the same thread) and across processes, for both POSIX and Windows, I am all ears. :-)
Leo Razoumov wrote:
>
> Simple patch below fixed the problem for me.
>
> @@ -275,7 +275,7 @@ static int lfs_lock_dir(lua_State *L) {>...
It fixes the compilation problem but that function is still
broken (racy, busy looping, potentional fd and mem leak,
strange algorithm).