X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C7C243858C2C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1706101922;
	bh=71MEYk6lzDRV0tM1pNq5GQaztegCczTadLR2AceYyUU=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=e9yRYOTykYD5Hk10EiZ50zcJl3bjZdX1TxwOwIHW3G0W+DaFhzFMZ0wnj8frkJYr5
	 QpaJ7A/ZBx4RjNqcmLo/fNb4jc7UkTsTDDCJ1MyKTsY0vt30BbrzKPrn+fr96ZwVEc
	 j7EmKHz+upJ0+9mghou//TlJP+t8G5DSEyvnNqFQ=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5DF093858D3C
Date: Wed, 24 Jan 2024 14:11:38 +0100
To: cygwin AT cygwin DOT com
Subject: Re: Possiblly bug of cygwin1.dll
Message-ID: <ZbEMiot8xnlKPj47@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20240119224436 DOT 876a055f356f7c6796bc725b AT nifty DOT ne DOT jp>
 <ZaqHGElhXZIc3NFX AT calimero DOT vinschen DOT de>
 <20240120131825 DOT 4157c259fe058155137d6fe0 AT nifty DOT ne DOT jp>
 <c90e29238d7bb99ef6a8787f38585c21 AT kylheku DOT com>
 <20240124205514 DOT eaaa7162e3e858cbb39f5801 AT nifty DOT ne DOT jp>
 <ZbELFu6Ly4U9UBZo AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <ZbELFu6Ly4U9UBZo@calimero.vinschen.de>
X-BeenThere: cygwin AT cygwin DOT 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 AT cygwin DOT com?subject=unsubscribe>
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: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On Jan 24 14:05, Corinna Vinschen via Cygwin wrote:
> On Jan 24 20:55, Takashi Yano via Cygwin wrote:
> > On Mon, 22 Jan 2024 19:24:52 -0800
> > Kaz Kylheku wrote:
> > > In real systems, the static distinction has no meaning.
> > > 
> > > This code can be inside a shared library:
> > > 
> > >    static pthread_mutex_t g_lock = PTHREAD_MUTEX_INITIALIZER;
> > > 
> > > this library could be loaded by dlopen and unloaded with dlclose.
> > > Thus static becomes dynamic!
> > > 
> > > And, by the way, this is a problem: if we have a library
> > > which does the above, and we repeatedly load it and unload
> > > it while using the mutex in between, it will leak.
> > 
> > As you pointed out, if dlopen()/dlclose() are called repeatedly,
> > handle leak might occur even if pthread_mutex_t is statically
> > allocated.
> 
> Cygwin 3.5 is due really soon now, so we can't change anything here,
> except fixing the pthread_once problem (@takashi, didn't you want to
> apply your patch?)
> 
> As for the next major release, do we have a chance to revamp
> pthread_mutex_t so that it does NOT dynamically create an OS synch
> object?  Is there a way we can change the really much too complex
> pthreads code to simplify things and use, say, SRWLOCKs, or any other
> synch mechanism which is faster and less intrusive?
> 
> The biggest problem, IMHO, is the DREADED fact that the original author
> of the pthreads code defined the exposed pthread types as, for instance,
> 
>   typedef struct __pthread_mutex_t {char __dummy;} *pthread_mutex_t;
> 
> So they only take 1 byte in user space and there's no chance to fit
> an SRWLOCK or, FWIW, a LONG value in there to be used with Interlocked
> functions.  That's really a problem we're kind of stuck with, I fear.

No, wait, I'm an idiot.  The types are defined as *pointers*, so
they have a size of 8 bytes in user code.  That means we should
be able to implement this differently, less dynamic, and still
be able to do it backward compatible.

We *really should try that and simplifying things at the same time.

Is anybody willing to give this a whirl?  We have a good year until
the next major release...


Corinna

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