Mailing-List:	contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin-developers/>
List-Post:	<mailto:cygwin-developers AT cygwin DOT com>
List-Help:	<mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-developers-owner AT cygwin DOT com
Delivered-To:	mailing list cygwin-developers AT cygwin DOT com
Message-ID:	<3D527A3C.40704@hekimian.com>
Date:	Thu, 08 Aug 2002 10:03:40 -0400
X-Sybari-Trust:	6009ee36 b923d9bf 4738785c 00000109
From:	Joe Buehler <jbuehler AT hekimian DOT com>
Reply-To:	joseph DOT buehler AT spirentcom DOT com
Organization:	Spirent Communications
User-Agent:	Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530
X-Accept-Language:	en-us, en
MIME-Version:	1.0
To:	Cygwin Developers <cygwin-developers AT cygwin DOT com>
Subject:	FYI on private static object construction

Just an FYI to the Cygwin team:

It appears from discussion on the gcc list that private static
objects in C++ functions are constructed when they are encountered
in program flow.  E.g.:

f()
{
     whatever...
     // "x" is constructed when program flow gets here
     static some_class x;
     whatever...
}

This construction is not thread-safe in gcc at present.  Nor does
it appear that it is required to be so by the C++ standard.  This
can result in multiple construction of the object, and multiple
parallel calls to atexit() (used to schedule destruction), which
is also not currently thread-safe, and can cause null pointer
dereferences.

So I would recommend that in Cygwin such objects be moved out of
functions to global scope, to avoid threading issues.

I suspect that this is what is causing my problems with atexit().

Gcc generates functions with "tcf" in the name (e.g. __tcf_0) for
this sort of code, so it is easy to tell whether a particular object
has the problem.

Joe Buehler

- Raw text -