Closed soulmachine closed 2 years ago
It is possible. Is the PID enough for the case when lock is held by handle and not by process?
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
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.
Is it better to erase the PID when unlocked?
Or should the PID be preserved until the next lock?
Better erase the PID when unlocked
Well, I believe I have an implementation for this on branch dev
, but I did not test it on Windows
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.
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
).
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.