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: Mail-Followup-To: cygwin AT cygwin DOT com References: <20240119224436 DOT 876a055f356f7c6796bc725b AT nifty DOT ne DOT jp> <20240120131825 DOT 4157c259fe058155137d6fe0 AT nifty DOT ne DOT jp> <20240124205514 DOT eaaa7162e3e858cbb39f5801 AT nifty DOT ne DOT jp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen 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" 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