From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id 2FD4C3858CDB; Wed, 24 Jan 2024 13:05:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2FD4C3858CDB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1706101529; bh=0Drqt3TXVZ0ez1J0hdVfzeofoE6IEAl/PYGKQxtIdME=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From; b=bXe/O5z1ZuyEco+z0NmLUYBbcgyEorMi2jaousoetal7f1v+ef+mIs/MCI3+5rHLT 6p7MBvAPTOhD8XKkgKWQB6UHoFqOJqqJoEKLJgVe64zAOEjLdckGyovbpCd7Pa20ur 8ozzEujFLQe6XEV4ypduth4Gq7heUU5Wl67WdF4w= Received: by calimero.vinschen.de (Postfix, from userid 500) id E3544A80B93; Wed, 24 Jan 2024 14:05:26 +0100 (CET) Date: Wed, 24 Jan 2024 14:05:26 +0100 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: Possiblly bug of cygwin1.dll Message-ID: Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20240119224436.876a055f356f7c6796bc725b@nifty.ne.jp> <20240120131825.4157c259fe058155137d6fe0@nifty.ne.jp> <20240124205514.eaaa7162e3e858cbb39f5801@nifty.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20240124205514.eaaa7162e3e858cbb39f5801@nifty.ne.jp> List-Id: 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