On Mon, Aug 19, 2013 at 10:58 AM, Martin Panter <vadmium+patch@gmail.com> wrote:
On 19 August 2013 08:48, Martin Panter <vadmium+patch@gmail.com> wrote:
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.
Sorry I got my processes mixed up at the end. Here’s the steps:
* Lock file exists with process X which no longer exists * Pacman process A starts and determines X does not exist * Pacman process B starts and determines X does not exist * Process A removes the old lock file which referenced process X * Process A creates a new lock file for itself (referencing process A now) * How do you make sure B does not delete the new lock file A just created?
How about this? * Open lock file with O_RDWR | O_APPEND | O_CREAT and read. -> If file is empty, we can run. -> If file contains a non-existing PID and the current hostname on its last line, we can run. * If we can run, write new line containing current PID and hostname. * Rewind file and read again. Verify content is as expected. * Do database operation. * Remove lock file. I'm not sure how well it works over a network. Maybe one or more fsyncs can be introduced to ensure the appending and reading is synchronized with the server?