Mail Archives: cygwin/2010/08/31/13:41:47
On Tue, Aug 31, 2010 at 05:26:24PM +0000, Magnus Holmgren wrote:
>Christopher Faylor <cgf-use-the-mailinglist-please <at> cygwin.com> writes:
>>Here's what I'm saying: It makes absolutely no sense that moving the
>>call would have any effect. The code is the way it is for a reason so
>>we're not going to just revert the change.
>
>I think it makes sense, if the signal thread initialization takes time.
>Which it does:
>
>69 15954 [main] date 2708 wait_for_sigthread: wait_sig_inited 0x4C
>13706 29660 [main] date 2708 wait_for_sigthread: process/signal
>handling enabled, state 0x41 146 29806 [sig] date 2708 wait_sig:
>entering ReadFile loop, my_readsig 0xFC, my_sendsig 0x100
>
>The above is a snippet from "strace date" (with some wrapping by me),
>using Cygwin 1.7.6 on Vista x64. And 1.7.7 is said to be slower still
>- and guess what, sigproc_init is called later; see r1.382 of dcrt0.cc.
You are using a different value of "makes sense". I was not saying
"Your observations are wrong". If I was saying that then yes, you would
not be making sense. Yes, if a function takes longer than you want it
to, then it will cause things to be slow. That does make sense but it
is basically a tautology.
I am saying that looking at the code, it does not make sense that it would take
longer. It especially does not make any sense given the fact that the signal
thread does not get started until well after dll_crt0_0 has exited, so, moving
the sigproc_init should not cause any difference in behavior. And, you really
haven't proved that it does since you are checking the difference between 1.7.6
and 1.7.7 and there have been many changes between those two.
cgf
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -