On Fri, Nov 21, 2025 at 2:00 AM Takashi Yano <[email protected]> wrote: > IIUC, flock() locks file itself, but not file descriptor. Usually, > flock() is used for inter-process file protection, isn't it?
It's kind of fuzzy: - on one hand: "Locks created by flock() are associated with an open file description" (Linux man page) - on the other: "Locks are on files, not file descriptors" (BSD man page) Either way, they both follow up by saying that if the descriptor is duplicated/forked/etc, the copies will share the lock. But then that's not my issue. lockf() is not an option. Since it's the same as fcnt(F_SETLK) (I believe), it does not prevent threads from accessing the same file at the same time (see fcntl_locking(2)); > F_SETLK [...] The threads in a process share locks. In other words, a > multithreaded program can't use record locking to ensure that > threads don't simultaneously access the same region of a file. fcnt(F_OFD_SETLK) could work: > F_OFD_SETLK [...] On the other hand, open file description locks may conflict > with > each other when they are acquired via different open file > descriptions. Thus, the threads in a multithreaded program can > use open file description locks to synchronize access to a file > region by having each thread perform its own open(2) on the file > and applying locks via the resulting file descriptor. but it's Linux specific and not supported by Cygwin AFAICT, so that's not an option either. > The linux man page for flock() does not mention about MT-safe > https://man7.org/linux/man-pages/man2/flock.2.html Neither does open()/read()/write()/close() other than when sharing the same file descriptor between threads. So flock() _on the same descriptor_, I think it's Ok to assume it's not MT-safe. But flock() _on different descriptors_, I do think it should be thread safe (and the "same-descriptor" case would still prevent it from being MT-safe as a whole). If not, then open/read/... shouldn't be considered MT-safe either and we all ought to use locks around them. Regarding the flock+open case, actually, I think it's just flock() corrupting the memory, which means that at that point, all bets are off and anything can happen, including open() failing. Using a mutex around the flock() call does seem to fix the problem. The sample app works fine with it, so does the Fish test which was still failing even when it didn't trigger any flock/open error or deadlock. (I still think flock() itself should be thread safe when using different descriptors though :p) Nahor -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
