regolancer.lock not deleted

[rkfg]

regolancer.lock not deleted

[rkfg]

It's a technicality, there's no way in the library we use to delete that file and I showed why it's not a good idea in our case. If you're supposed to run exactly one instance of software and it holds the lock during the entire run time then I think it might be deleted safely on exit. But people run multiple regolancer instances, up to 40 in parallel, so deleting the lock might cause unexpected race conditions this lock should prevent exactly.

[rkfg]

See gofrs/flock#41. I suppose it's unsafe to delete lock files in general if we expect many processes to run in parallel. Consider this situation:

• process1 acquires the lock for writing
• process2 tries to do the same but is blocked because of process1
• process1 finishes the work, unlocks the file
• process2 quickly locks it to itself
• process1 doesn't know that, deletes the file and exits (here it would fail on Windows but not on *nix)
• process3 attempts to acquire the lock, the file doesn't exist so it creates and locks a new one with the same name
• process2 still uses the (now deleted) lock
• process3 also uses the lock because it created a different file with the same name

And here we have process2 and process3 using the "exclusive" lock together at the same time.

[feelancer21]

But this means, that I have to delete the lock by myself before starting a new run? Otherwise, I think, no process can write in the db.

[rkfg]

Have you tried just running the program? I never deleted the lock and it all worked fine even when I ran 3-4 processes at once. The mere presence of that file doesn't mean it's locked, flock is a special syscall (see man 2 flock) which places a lock on an existing file or blocks if it's already present. That's why we use a library for this and not simply create/check for an empty file, this stuff isn't cross platform and needs explicit support with platform API.

Oh, and also we don't have a db except the optional CSV stat file. It's currently not protected by the lock but it will be soon. If you mean the node cache, it's also not a db but a gob dump and it's only written when the program terminates. This is protected by the lock.

[feelancer21]

The program seems to work. But sometimes there is a difference between what you see and what happens.
But I am not so deep in the technical details. I was just wondering because the file existis and worried that there is still something locked. And yes I mean the node cache.