dll_entry [was Re: fork expert needed: (was .....])

Robert Collins robert.collins@itdomain.com.au
Mon Apr 16 06:13:00 GMT 2001

----- Original Message -----
From: "Trevor Forbes" <trevorforbes@ozemail.com.au>
To: "Cygwin-developers" <cygwin-developers@cygwin.com>
Sent: Monday, April 16, 2001 11:04 PM
Subject: dll_entry [was Re: fork expert needed: (was .....])

> ----- Original Message -----
> From: "Christopher Faylor" <cgf@redhat.com>
> >
> > > Robert Collins wrote:
> > >Also while MSDN states that only one thread at a time can call the
> > >entry point function, it does not state or imply that other threads
> > >suspended during that process.
> >
> > Ok, I reluctantly stand corrected.  I thought that both the MSDN and
> > my own personal experience (waiting for a signal from Cygwi's signal
> > thread that never arrived) said this.  I couldn't find any reference
> > to this, though.
> Moved thread  location.....
> The system serializes calls to the dll entry point function and "it
> suspends" the other related threads during the process.
> (Jeffery Richer - Microsoft Press)

I believe that means that if (say) 3 threads (whether in the same
process or not) simultaneously attach to a single dll, two of the three
threads are blocked while they wait to run the dll entry point function.
That's not the scenario we were discussing. Still, a test case will
demonstrate it wiether way quite quickly.

More importantly, we're not in cygwin's dll entry point, so that is
irrelevant to us. We may cause other dll entry point functions to run as
we call LoadLibrary multiple times (once for each dll the parent had
attached to before fork was called).

> The attached patch can avoid the bottleneck but it may introduce
> problems.

It won't avoid the issue we're looking at :[ Other than that, no comment
from this corner - too ignorant of cygwin's needs in that area at the


More information about the Cygwin-developers mailing list