brunoczim / fslock

File locking for Rust.
MIT License
40 stars 11 forks source link

Can we write pid to the lock file? #5

Closed soulmachine closed 2 years ago

soulmachine commented 2 years ago

It would be useful if the lock file contains the PID. It's common user case that during debugging we want to know which process is holding the lock.

brunoczim commented 2 years ago

It is possible. Is the PID enough for the case when lock is held by handle and not by process?

soulmachine commented 2 years ago

I recently got a deadlock issue between multiple processes, lack of PID is a pain when debugging. It took me hours to resolve it https://github.com/soulmachine/crypto-crawler-rs/commit/eda33b5f4e02728b4135b432230c06481356192e

brunoczim commented 2 years ago

I think it is reasonable to write it indeed. I would prefer this is optional. We could have a new method that opens and writes PID or perhaps a builder which can be configured to write the PID on open.

I might implement it by myself, but anyone who'd like to implement it is welcome.

brunoczim commented 2 years ago

Is it better to erase the PID when unlocked?

Or should the PID be preserved until the next lock?

soulmachine commented 2 years ago

Better erase the PID when unlocked

brunoczim commented 2 years ago

Well, I believe I have an implementation for this on branch dev, but I did not test it on Windows

brunoczim commented 2 years ago

Ok, the PID writing by itself is correct in Unix version, but I found a bug on it unrelated to writing PID (see #6) .

For Windows, I am having a small trouble. LockFileEx is not advisory as in Unix's lockf, but mandatory. So, if we write the PID, nobody will ever see it, because the file is locked.

brunoczim commented 2 years ago

I solved Windows problem by locking just the very last possible byte of a file (and not the actual allocated last byte).

So, I'd say this is solved. I will publish a new version when I can, but first I need to be sure about the solution of #6 (I replaced lockf with flock).