This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
dll_entry [was Re: fork expert needed: (was .....])
- To: "Cygwin-developers" <cygwin-developers at cygwin dot com>
- Subject: dll_entry [was Re: fork expert needed: (was .....])
- From: "Trevor Forbes" <trevorforbes at ozemail dot com dot au>
- Date: Mon, 16 Apr 2001 22:34:22 +0930
- References: <037701c0c3ab$9049bf30$0200a8c0@lifelesswks> <20010413221222.C5606@dothill.com> <006001c0c4af$179b79c0$0200a8c0@lifelesswks> <20010414223139.A906@redhat.com> <001701c0c557$02a861b0$0200a8c0@lifelesswks> <20010415090600.A8359@redhat.com> <001301c0c5af$9cb7e520$0200a8c0@lifelesswks> <20010415153317.C9015@redhat.com> <013b01c0c613$53cdac00$0200a8c0@lifelesswks> <20010415222520.E10309@redhat.com>
----- 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 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)
The attached patch can avoid the bottleneck but it may introduce new/old
problems.
Part of the patch is a reversal of a previous patch
http://sources.redhat.com/ml/cygwin-cvs/2000-q2/msg00041.html
What was the purpose of this patch?
Calling DisableThreadLibraryCalls could provide a cheap performance boost by
telling the system to not send DLL_THREAD_ATTACH and DLL_THREAD_DETACH
notifications to dll_entry when creating and destroying threads.
Any thoughts / has it been tried before / a bad idea ?
Regards Trevor
dll-init.patch
dll-init.ChangeLog