On 07/04/14 12:33, Arran Cudbard-Bell wrote:
flock is sometimes just a wrapper around fcntl so may be just as broken, at least by moving to something we know is broken in terms of reflecting lock states internally, it means that we'll account for it in the code
True; it was working on native-flock-supporting systems accidentally in the old case, I bet. Worth noting that flock() locks are inherited across fork/exec too (including exclusive locks). Which is nice...
Anyway, I've just added a mutex around the writes for now.
I'm not sure that logic is right; doesn't the lock free (implicit in close()) need to be inside the mutex too?
I spent a few days investigating locking schemes on *NIX a while back and , came to the conclusion the only sane way of implementing a sane file locking scheme is to have a structure in the server core which holds all the currently open file handles, and their lock states.
Yes, it's a shame the APIs are so terrible.