DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 5AN5nrdP774068
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 5AN5nrdP774068
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=IUDs0au4
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 12E913858C78
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1763876992;
	bh=XWhhfU1qxDRYoeQYLy8bTn5U+x1z8YvhRT/SyNXOT5E=;
	h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=IUDs0au4hpPU1ilpnlzlcp/l5+TTo6GEcKJCZ32j9JhkF8odnMYvalGP8IvmD91yL
	TY8AGiN4MK04aRRiUshijruMNtU781dZh/JFiJdCTXi7XpADsD4/ukMuh1Lb+fVyvB
	Cr8mVh9USrPOn5wqXARH52mqhMjVyIjJTAd6VBLg=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org A03C63858D21
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org A03C63858D21
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1763876932; cv=none;
	b=o7AQxjgClmpuh8ErusmR/tOS3jjz7uYILpl8cCaanq41z/iTGl8FjeK1JMfT+BFNhcxdp1kC4wPz90FnfhpgeQB+Q5+urK5UDwGg7feGQU7aYvYJmE5PnTBJnIba2cRm8WBx+mInQ5ZzNVqeZ417Zgj9xhcoA9yhV3uG5z8/hkE=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1763876932; c=relaxed/simple;
	bh=nFxUXHvtF6WkdIWg+ZbHyPY4yLWI3yfIEGnMjSjbz6E=;
	h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To;
	b=mocOzFG7uZ7qzjxQvfCUu6zrORg0CRmL+Dhs6vU/C8uLkWChLf/5UJNPI77dW8C/WMBY/9FZcE1CeAo/1iK0gt7sH8ZyXOHvBbXimbaWyMwvmre55hrG+TGw04jER2gers8w2AD+KdCyrgXld7Nu12Kx4AWXcrh2FFistkOi8w8=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org A03C63858D21
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20230601; t=1763876932; x=1764481732;
	h=content-transfer-encoding:to:subject:message-id:date:from
	:in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from
	:to:cc:subject:date:message-id:reply-to;
	bh=XyzQynAjo0IMjgLnyaJ7bJcjkG9pyYWiDR3kR+kr5og=;
	b=ZuuusvX2wOGk0yU0d6FGkF7KQZMC43sQgS/Ahng7QXbreAar4yOFfFFPXg6lylLPMP
	Cv7bvQnYJ8evTZ88iofRbGNIQvGEdtTPdi2pmdJ+c214qlNzJmk7BS72gs2hTwT0hPC+
	DJEamn3wTfFZ+7wAedRclDhoe1h2kQ8JgzWNwW2dMhxcua4vLOH39iah7nB5xCfuM8gc
	go0HRGd+ZVy9mqXPfKwbjKitoTjkaQXPcOGsu+uXwbbKnrqENItD4z1xIHNAo+5MNPOa
	0x17L4ooJTfuwx2Bbc8nNo1oTlxv8ldyPpxw/LZxXXkU8G9QESOnMC5DwyjyGSnhyU4L
	ph3A==
X-Forwarded-Encrypted:	i=1;
	AJvYcCUerfRp8ItvKCh+ObOGwMbzxxSn43xclgeJRdEkUn1USrDp2pMZRlMP7uHlNENIf1kALqG5uQw=@cygwin.com
X-Gm-Message-State:	AOJu0YwoDDmM4J3j/9ISxa4tZEZUSK+/fnMeRBXqYJswxU+94shH9pbQ
	eK49RDKyyQ2uCJGNigFirIo6n3BUoCmHXzlTzF9bi5eCrUM7x+TLj1KwZYGrDB/MS2IWwMV+mKI
	uv22xFtJxYyY/u8me16Ixuh1NxozJMYSTIh775Q==
X-Gm-Gg:	ASbGncvC52ySHSTp3Dv7+k4id+BDZ7jd6R7ZATDcFV89BpmS2SVrgWWCQsRNKmqvgd/
	xFbnrukYOPAnDWlOvact1oQrBLqngzpR9mVbsVKqtxu2n16HO9CaQJIWEiAMff7AWY2308p9RgI
	nJiKmIYEZDYpSvD0FsGudtoEkrN+QKinwkPXIFWiaYMFxXzDDLmYpWvLs53QFwgaVC2HSALO7VU
	gXdbesAaxLM065J+zNOGa2jM3QCzAnx70g7puTU/XCvm1LUiUxr8R89OvwbUgWvvEQyiZGs+jKN
	8zK9u3AmCkDeabRpjl69keuI7w==
X-Google-Smtp-Source:	AGHT+IHOatJ05aQg5VMFRSKfMG+i0JGRXYS87g9dXIv9QHLwrKxq63jCiPlSLRqgUvkQgthznWUuFo33I+sD8unYIaQ=
X-Received:	by 2002:a05:690c:930d:10b0:78a:a2f1:140d with SMTP id
	00721157ae682-78aa2f11542mr1142137b3.3.1763876931765; Sat, 22 Nov 2025
	21:48:51 -0800 (PST)
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
X-Gm-Features:	AWmQ_bmjLDDiWY06GFWvbSdUYmlpOKxyZOxgQ5_qqpigi2IVbUpjtPLWPn21AJQ
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
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Nahor via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Nahor <nahor.j+cygwin AT gmail DOT com>
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 5AN5nrdP774068

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

- Raw text -