This is the mail archive of the cygwin-developers@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [take 2] Re: (patch) makethread stdcall/cdecl confusion


Chris Faylor <cgf@cygnus.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]