You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
InterProcessLock silently fails if multiple locks on the same file are created in multiple threads of the same process. All threads can acquire the lock, because their process already owns the lock and fcntl.lockf() returns without error. This is obvious if you know how InterProcessLock is implemented and how file lock work on the OS level, but still may surprise users (including myself) and result in hard to debug and reproduce bugs. For example, most deployment options for web applications allow both thread- and process-based concurrency, or even a combination of both. An app might work in one environment but silently fail in other deployments.
To follow the principle of least surprise, InterProcessLock should also acquire thread-level locks, or come with a very visible warning that it does NOT work as expected in multi-threaded environments. I'd love to see a new lock implementation that combines both lock-types in a save way. This would perhaps also help avoid confusion for developers using this library.
The text was updated successfully, but these errors were encountered:
InterProcessLock
silently fails if multiple locks on the same file are created in multiple threads of the same process. All threads can acquire the lock, because their process already owns the lock andfcntl.lockf()
returns without error. This is obvious if you know howInterProcessLock
is implemented and how file lock work on the OS level, but still may surprise users (including myself) and result in hard to debug and reproduce bugs. For example, most deployment options for web applications allow both thread- and process-based concurrency, or even a combination of both. An app might work in one environment but silently fail in other deployments.To follow the principle of least surprise,
InterProcessLock
should also acquire thread-level locks, or come with a very visible warning that it does NOT work as expected in multi-threaded environments. I'd love to see a new lock implementation that combines both lock-types in a save way. This would perhaps also help avoid confusion for developers using this library.The text was updated successfully, but these errors were encountered: