Mail Archives: cygwin-developers/1999/09/17/12:05:30
On Fri, Sep 17, 1999 at 08:48:19AM -0500, Mumit Khan wrote:
>Chris Faylor <cgf AT cygnus DOT com> writes:
>> 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 ;-)
The "the" "reason for the synchronization" was referring to the
particular case that we are referring to.
Since, AFAIK, we were not referring to the generic uses of synchronization
I am again confused as to why you're even mentioning this.
>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).
Again, you are mentioning signals in the context of synchronizing between
makethread and thread_stub. I don't understand why.
The intent of the CreateEvent/WaitForSingleObject in makethread and the
SetEvent in thread_stub is to ensure that the stack in makethread is
in a known state for use by thread_stub.
Mumit, either I'm dense (which is certainly possible) or you are not
explaining the purpose of this patch very well. It's obviously trivial
to remove the synchronization by using malloc. Now it seems that
possibly you want to remove this so that possibly you can call
makethread from DLL initialization. I can see why this would be
important since DLL initialization is serialized. I am only inferring
this because you don't seem to be stating this anywhere.
What confuses me is that so far the only changes I've seen from you
kept in the synchronization but changed the code from using information
on the stack to using information on the heap. To me, there is no
clear reason for doing this.
>> 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.
The synchronization in makethread/thread_stub has nothing in particular
to do with sig_send or wait_sig. As you mentioned, I have recently
added a sig_send (NULL, __SIGFLUSH) prior to the call to main so that it
is guaranteed that a process can receive signals once it is in user
code. Other than that, there is nothing, that I am aware of, which
relies on the wait_sig thread being in any particular state which
would come from some funky thing or other in makethread/thread_stub.
>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.
I believe that I mentioned that the code should have been commented.
Possibly that's where you got this argument. So far, the original
author hasn't forgotten why the synchronization was being done but he
will admit to not commenting this code.
>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.
I can't say that I disagree because I still don't understand why you
think this change is so important.
Since I do understand the code in makethread and thread_stub thoroughly,
I'm not, in this case, going to say "Ok, just make the change then".
If you are trying to accomplish the initialization of the signal thread
from the DLL initialization, then I guess I understand your rationale.
cgf
- Raw text -