Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Unsubscribe: <mailto:cygwin-developers-unsubscribe-archive-cygwin-developers=delorie DOT com AT sourceware DOT cygnus DOT com>
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-Id: <199909171348.IAA14056@mercury.xraylith.wisc.edu>
To: Chris Faylor <cgf AT cygnus DOT com>
cc: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: [take 2] Re: (patch) makethread stdcall/cdecl confusion 
In-Reply-To: Your message of "Thu, 16 Sep 1999 22:43:34 EDT."
             <19990916224334 DOT A5928 AT cygnus DOT com> 
Date: Fri, 17 Sep 1999 08:48:19 -0500
From: Mumit Khan <khan AT xraylith DOT wisc DOT EDU>

Chris Faylor <cgf AT cygnus DOT com> writes:
> I still don't understand.  You seem to be going with the malloc()
> mechanism because using the stack is "bad".  No matter how you
> slice it, your version is slower and it doesn't have any advantage
> over the current one.

The purpose was not to reduce overhead. See below.

> In fact, malloc() uses its own synchronization mechanism so even if you
> remove the event synchronization you could still end up with as much or
> more overhead than the current method.  So, you could eliminate the
> event signalling with the use of malloc(), but I'm not 100% certain
> that it would buy you anything.
> 
> As I mentioned, the reason for the synchronization is to *ensure* that
> the stack in the initiating thread is in a known state.  It's the whole
> reason for the synchronization.

You mean `... reason for *this* particular instance of synchronization'.
Synchronization has a few other uses ;-)

My next patch (if it tests out ok) removes the synchronization completely.
This has the added benefit of being able to use signals from a noncygwin
app as well, without having to maintain a separate flag when the DLL is
being dynloaded by an MSVC main application (such as Java). 

> I'm not sure why you're mentioning sig_send in this context.  Maybe
> you meant wait_sig.  sig_send will wait for wait_sig if it wait_sig
> has not finished initializing.

Because sig_send is crucial in this respect! See dcrt0.cc:dll_crt0_1 for
how it's used at DLL startup to test out the signalling thread and flush
it out. The DLL uses `sig_send (NULL, __SIGFLUSH)' to ensure that the
signaling is running and happy, and if it's not, it'll hang until it
is. Before I submit my next patch, I need to make sure that the 
signalling thread is up and running *without* having to synchronize
before the sig_send(...) is called.  I think it does, and simple tests 
show that it does, but need more testing for my own peace of mind.

I don't mind trading off overheads as long as the newer scheme *removes*
hidden gotchas that may show up when an unrelated part of the code 
changes; in this particular case, the synchronization part should've 
had clear comments as to the reason since it is *not* obvious why it's
being done. Someone else modifying the code (even the original author 
after a while) may forget and remove/change the synchronization and run 
into bizarre problems. 

In any event, if you're not interested in such a change (or disagree with
my rationale), drop me a line and I'll simply not work on this aspect. 

Regards,
Mumit