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
Date:	Wed, 5 Mar 2003 00:08:09 -0500
From:	Christopher Faylor <cgf AT redhat DOT com>
To:	cygwin-developers AT cygwin DOT com
Subject:	Re: gcc static constructor multi-threading flaw
Message-ID:	<20030305050809.GB29712@redhat.com>
Reply-To:	cygwin-developers AT cygwin DOT com
Mail-Followup-To:	cygwin-developers AT cygwin DOT com
References:	<3E4D06B8 DOT 5010306 AT hekimian DOT com>
Mime-Version:	1.0
In-Reply-To:	<3E4D06B8.5010306@hekimian.com>
User-Agent:	Mutt/1.5.1i

On Fri, Feb 14, 2003 at 10:09:44AM -0500, Joe Buehler wrote:
>Would you accept patches to gcc / cygwin to add locking to
>function-private static object constuction?
>
>Gcc generates calls to atexit() when entering a function that has a
>private static object.  It does this to schedule a call to the
>destructor at program exit time.
>
>The atexit() function is not thread-safe, however.  I posted an
>explanation to the newlib list, but looking at the newlib code, it
>appears that newlib is not really set up for locking, so a fix is
>probably not going to be forthcoming from there.
>
>One possible fix is to have gcc call a wrapper function that performs
>locking and then calls atexit().  I suppose another way to do it
>without touching gcc is #define manipulation to replace atexit() with a
>Cygwin wrapper.

Since neither gcc nor newlib have responded to this problem, I've
added a wrapper in cygwin.  It will be in 1.3.21.

cgf

- Raw text -