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