X-Recipient: archive-cygwin@delorie.com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E72B53858427
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1706128685;
	bh=qjoHP7rm7d4Nrp218ix3n6bKhr/AIK9ZDpDLkr1jJ4s=;
	h=Date:To:Cc:Subject:In-Reply-To:References:List-Id:
	 List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe:
	 From:Reply-To:From;
	b=KzHlb8oNk7+pmuVZqty4eYLHO8lvhb8qlMilVlwY5JVNCgLEKZaGUNsL9HqZ+/t82
	 mKLTMsxOa5n8QGWuVqImYtSYRhzVp85WMCwtPkhcpVxMhVLIz/lCks1Q5R68XeuAAJ
	 RHajR+e8/b3EGqJ7VSliTKLqJW6QARifT64/1BOU=
X-Original-To: cygwin@cygwin.com
Delivered-To: cygwin@cygwin.com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 12AD23858D28
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 12AD23858D28
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706128637; cv=none;
 b=vNPLTpBlrPPHvRu2ML8U/ZtfxieAH+PhD2r/4gyufB05htNTLKtXV1IbxwZfYFxt4Yt37LPq/NWRGWd7jg23neb/6ilmmkOWh86VPLiXW2CodAssKgXXOU/mvicdDMyDG4UuLW4KIvm04EgVHhGoo+go6p/O4uJJPBFGIBwjfrs=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1706128637; c=relaxed/simple;
 bh=ZL6Ix5yQpiR2KqVXJ6RcyD9KRgBUDY50MZ5eaoU8PNU=;
 h=DKIM-Signature:MIME-Version:Date:From:To:Subject:Message-ID;
 b=QY5IM5sq5dCv9kLiohVtLW6FjSp48IagAPo+iZHDWzcH1Sfw082z4g2G5sBFij5SRc2rPmQlb9w+sFEqv3NsXFrxGg3HqQxln3sD/ZBBSADqchMu4bq5+iee7425aYia8p3FclXfoEAlfZt5Ry5BP4PpesfcC0kzQXkrhVBheeQ=
ARC-Authentication-Results: i=1; server2.sourceware.org
X-Authority-Analysis: v=2.4 cv=Qcx1A+Xv c=1 sm=1 tr=0 ts=65b174fb
 a=pMSlDXUwMa7SJ1EIez8PdQ==:117 a=pMSlDXUwMa7SJ1EIez8PdQ==:17
 a=kj9zAlcOel0A:10 a=dEuoMetlWLkA:10 a=SeMdBNsBWc165JoUstMA:9 a=CjuIK1q_8ugA:10
MIME-Version: 1.0
Date: Wed, 24 Jan 2024 12:37:13 -0800
To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>
Subject: Re: Possiblly bug of cygwin1.dll
In-Reply-To: <ZbEMiot8xnlKPj47@calimero.vinschen.de>
References: <20240119224436.876a055f356f7c6796bc725b@nifty.ne.jp>
 <ZaqHGElhXZIc3NFX@calimero.vinschen.de>
 <20240120131825.4157c259fe058155137d6fe0@nifty.ne.jp>
 <c90e29238d7bb99ef6a8787f38585c21@kylheku.com>
 <20240124205514.eaaa7162e3e858cbb39f5801@nifty.ne.jp>
 <ZbELFu6Ly4U9UBZo@calimero.vinschen.de>
 <ZbEMiot8xnlKPj47@calimero.vinschen.de>
User-Agent: Roundcube Webmail/1.4.15
Message-ID: <d49ef9656b451a77a47fc7252acc0f4d@kylheku.com>
X-Sender: kaz@kylheku.com
X-CMAE-Envelope: MS4xfEqocMsHHmipcdn7M01jDWyAk3nEdq5KYEesa3JPzGeujVfXzgKXegL3d7cHDDDbOCGNUauqE+HoeK/YO4flS7y8WkGxv3ZMuXT+aVi/g46kpO6enSZ7
 GeRk3wnoAaBAt3h2VPqzNwybclHkHH/m5fD04kz8CNMsniDQyxB7D/KTqMarx0zkuiN8asnhLO9IX8y9IZICviqdzEqU3EtnzkM=
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, DKIM_SIGNED,
 DKIM_VALID, DKIM_VALID_EF, HEADER_FROM_DIFFERENT_DOMAINS, RCVD_IN_DNSWL_LOW,
 SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-BeenThere: cygwin@cygwin.com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request@cygwin.com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-request@cygwin.com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request@cygwin.com?subject=subscribe>
From: Kaz Kylheku via Cygwin <cygwin@cygwin.com>
Reply-To: Kaz Kylheku <kaz@kylheku.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

On 2024-01-24 05:11, Corinna Vinschen via Cygwin wrote:
> Is anybody willing to give this a whirl?  We have a good year until
> the next major release...

As far as the problem of not allocating per-mutex kernel objects,
this can be done by implementing futex.

Linux has futexes, mainly for solving certain problems having to do
with doing synchronization efficiently in user space, while requiring
the kernel to actually make threads wait.

But the technique has an attractive aspect in that programs do not
have to allocate and free futexes. Any memory location is a futex.

(A vaguely similar idea was implemented in early Unix: the "wait
channel" (wchan). Any memory location in the kernel could be waited
on and signaled, without allocating or freeing any sync object.
That's where the wchan field comes from in ps; showing the address
of what the process is waiting in. Because the wait channel had
no state, any address could be used. Addresses of functions were
used, because those could be resolved back to meaningful names via
the symbol table. Futexes have state, though.)

-- 
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
