This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16285] thread-safe file locking (using lock file)
- From: "neleai at seznam dot cz" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 11 Jan 2014 11:37:47 +0000
- Subject: [Bug libc/16285] thread-safe file locking (using lock file)
- Auto-submitted: auto-generated
- References: <bug-16285-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16285
Ondrej Bilka <neleai at seznam dot cz> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |INVALID
--- Comment #9 from Ondrej Bilka <neleai at seznam dot cz> ---
> No it does not. As mentionned above. EEXIST does not enable the safe removal of
> stale lock files. The problem is the handling of stale lock files in a multi-
> threaded program:
> - either they exist indefinitely and the threads are locked until a manual
> intervention is performed
> - either they are replaced automatically with the risk of a race condition,
> because using "link" requires "unlink" and 2 threads can execute "unlink"
> simultaneously without knowing that they are removing a new valid lock file
> from another active thread.
If file exists you could simply lock it. For safely unlinking first get lock,
then open file again and check if inodes agree and unlink file if they so.
--
You are receiving this mail because:
You are on the CC list for the bug.