Re: Possiblly bug of cygwin1.dll

[Corinna Vinschen <corinna-cygwin@cygwin.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