X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 296AE385840E
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1706101588;
	bh=TfVuzG9+5/jqZP6JhBZSSffxEGi2zES0FrVJ1hPh/Fg=;
	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=HUJI7lLTSkWsSPT1CKndXe/CJ/DVHMKuOfjkVQgOfrQz4WGs5v2GglAkCgiuGgJDm
	I+ZDRzO3+DB8gQPlCnHsjgMyG69r+6neuKKVNbT2S+BjOf7hPc0aDzIEHVoEAzSuMP
	a7+6wzVJHyghkckGhY2Kb/y1emqz3gZy+oubk1ZM=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 2FD4C3858CDB
Date:	Wed, 24 Jan 2024 14:05:26 +0100
To:	cygwin AT cygwin DOT com
Subject:	Re: Possiblly bug of cygwin1.dll
Message-ID:	<ZbELFu6Ly4U9UBZo@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>
MIME-Version:	1.0
In-Reply-To:	<20240124205514.eaaa7162e3e858cbb39f5801@nifty.ne.jp>
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-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>
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 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.


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

- Raw text -