DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 5AN5nrdP774068
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A03C63858D21
MIME-Version: 1.0
References: <CA+1R0VjcBajGpLMJ_0Waie0g_5S15_kPfzpT2=GUyN+39RWrMw AT mail DOT gmail DOT com>
 <20251112182412 DOT ba3a65f36838b9b5fd7d3f9b AT nifty DOT ne DOT jp>
 <CA+1R0VjW5rbKAVBb_vAFqKcKmE0yfvOFi6i0-GB=2-mjOhCY7A AT mail DOT gmail DOT com>
 <20251121190009 DOT f08a3229007bbbf101ad1463 AT nifty DOT ne DOT jp>
In-Reply-To: <20251121190009.f08a3229007bbbf101ad1463@nifty.ne.jp>
Date: Sat, 22 Nov 2025 21:48:41 -0800
Message-ID: <CA+1R0VjRuU2V_j7aF4=_8KQa4E7D7dH071euo=Fdpweq8NH8mg@mail.gmail.com>
Subject: Re: flock/open random error
To: Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp>, cygwin AT cygwin DOT com
From: Nahor via Cygwin <cygwin AT cygwin DOT com>
Reply-To: Nahor <nahor.j+cygwin AT gmail DOT com>
Content-Type: text/plain; charset="utf-8"
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

On Fri, Nov 21, 2025 at 2:00 AM Takashi Yano <takashi DOT yano AT nifty DOT ne DOT jp> 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