Mail Archives: cygwin/2010/08/30/12:35:24
On Aug 30 10:26, Edward Lam wrote:
> Hi,
>
> In looking at slowdown problem on x64 systems by Sagi Ben-Akiva, I
> found some puzzling code that perhaps someone could enlighten me on.
> I must be reading it wrong.
>
> Here's the code path that I'm tracing using cygwin-src-20100829.tar.bz2:
>
> - In dcrt0.cc, if dynamically_loaded is true, then we call sigproc_init().
>
> - In sigproc.cc, sigproc_init() creates a new thread:
> hwait_sig = new cygthread (wait_sig, 0, cygself, "sig");
>
> - This calls the cygthread constructor for LPTHREAD_START_ROUTINE.
> (Actually, this doesn't really matter because the constructor for
> LPVOID_START_ROUTINE looks like it has the same problem.)
>
> - The cygthread constructor calls create(). But prior to this, the
> following class members are initialized:
> __name, func, arglen, arg, notify_detached
>
> - The following class members are NOT initialized (assuming that the
> macro DEBUGGING is NOT set):
> inuse, id, h, ev, thread_sync, stack_ptr, is_freerange
>
> - Ok, now the cygthread constructor calls cygthread::create()
>
> - In cygthread.cc, cygthread::create() immediately checks the value
> of the variable "h". But as mentioned previously, this is a variable
> that has not been initialized yet.
>
>
> What am I missing?
cygthread::operator new(size_t)
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
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 -