Can we write pid to the lock file?

[soulmachine]

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]

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

[soulmachine]

I recently got a deadlock issue between multiple processes, lack of PID is a pain when debugging. It took me hours to resolve it crypto-crawler/crypto-crawler-rs@eda33b5

[brunoczim]

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]

Is it better to erase the PID when unlocked?

Or should the PID be preserved until the next lock?

[soulmachine]

Better erase the PID when unlocked

[brunoczim]

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

[brunoczim]

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]

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).