Use system wide file locks to synchronize log files. #1605
Conversation
The global semaphore has been observed to not be released on unix like platforms when the process exits. So, we convert to file locks, which will be released on process exit on unix like platforms. Unfortunately, Win32 file locks and POSIX file locks have slightly different semantics in that Win32 locks are mandatory and POSIX locks are advisory, which can result in slightly different behavior. OTOH, this should fix the client deadlocking until the system is restarted, so this should be an overall win.
|
Has this been tested on macOS yet? It's implied that file locks should automatically release on macOS - but I didn't check myself. |
I tested it on my mac mini insofar as making sure that running multiple clients did not break in surprising ways. I haven't done any testing where the client crashes while the lock is being held, yet. |
|
Not a huge surprise - but I validated that macOS will release the file locks if the process is unexpectedly terminated. |
Thanks! I've been forgetting to fire up the Mac and verify that. Did you also perchance check to see if the client deadlocks without this? |
I've had it deadlock before and have had to manually delete the lock file that was created. My assumption had been the Windows client had the same issue - until I read the source. |
|
Oh, this is still open. Any objections to this being merged? |
|
Nothing from me |
This is an alternative to #1603, inspired by #1603 (comment).
The global semaphore has been observed to not be released on unix like platforms when the process exits. So, we convert to file locks, which will be released on process exit on unix like platforms. Unfortunately, Win32 file locks and POSIX file locks have slightly different semantics in that Win32 locks are mandatory and POSIX locks are advisory, which can result in slightly different behavior. OTOH, this should fix the client deadlocking until the system is restarted, so this should be an overall win.