| delorie.com/archives/browse.cgi | search |
----- Original Message ----- From: "Trevor Forbes" <trevorforbes AT ozemail DOT com DOT au> To: "Cygwin-developers" <cygwin-developers AT cygwin DOT com> Sent: Monday, April 16, 2001 11:04 PM Subject: dll_entry [was Re: fork expert needed: (was .....]) > ----- Original Message ----- > From: "Christopher Faylor" <cgf AT redhat DOT 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 are > > >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 new/old > 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 moment. Rob
| webmaster | delorie software privacy |
| Copyright © 2019 by DJ Delorie | Updated Jul 2019 |