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
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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