On 19/08/2013, Allan McRae <[email protected]> wrote: > On 19/08/13 13:44, Jan Alexander Steffens wrote: >> On Mon, Aug 19, 2013 at 5:39 AM, Allan McRae <[email protected]> wrote: >>> I stored the process ID in the lock file during creation many years ago. >>> Is there a portable way for us to determine if that process ID is still >>> running and remove the lock file automatically if it is not? >> >> Try to kill the PID with signal 0 and remove it if it fails with ESRCH?
Pardon me if I don’t know enough details of Pacman’s locking, but this sounds like a race condition, defeating the purpose of a lock. Even on a single machine, what happens if two instances A and B have both decided the old process does not exist, then instance A removes the old lock, and creates a new valid lock for itself, just before instance B also tries to remove the old lock? How do you stop A from illegally removing B’s valid lock? Maybe you could have a two stage thing or something but it’s getting a bit complex a.k.a. silly. > After discussing on IRC with Jan, this whole approach has issues... > > It would be fine for the local db lock, but not for the sync db or > package cache which might be accessed by multiple systems. > > Perhaps we'd require the pid and a machine identifier? Of course, we > could not clear leftover lock files from other machines, but we'd still > fix the majority use case. > > Allan
