Mail Archives: cygwin-developers/1999/09/17/11:00:37
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
- Raw text -