From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id 5DF093858D3C; Wed, 24 Jan 2024 13:11:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5DF093858D3C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1706101900; bh=mEt+gBkVg4lv6eu9BxLK/5giDh3KKes5N4kOGt3cAIg=; h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From; b=kAxehkXgR/l6QLZ4vK8epab71Njvudr2MuZdiq8UznTVa1PuDdWMDZSP+4B09A8Bg +nMy+TAjLzHHLCmFnrLWz56bcf/ZaIkMUhQ6r7n90mxwIjCQlL2oCbt9igy+HbERBT 0J4hBMOgMCYU9YajkQE0Tlyoqv6zZg2M5z14Do5g= Received: by calimero.vinschen.de (Postfix, from userid 500) id AA154A80B93; Wed, 24 Jan 2024 14:11:38 +0100 (CET) Date: Wed, 24 Jan 2024 14:11:38 +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: List-Id: 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