cvs.gedasymbols.org/archives/browse.cgi | search |
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: | <3E4D06B8.5010306@hekimian.com> |
Date: | Fri, 14 Feb 2003 10:09:44 -0500 |
X-Sybari-Trust: | b66e2920 f29b823d 2b08c392 00000139 |
From: | Joe Buehler <jbuehler AT hekimian DOT com> |
Reply-To: | jbuehler AT hekimian DOT com |
Organization: | Spirent Communications, Inc. |
User-Agent: | Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021212 |
X-Accept-Language: | en-us, en |
MIME-Version: | 1.0 |
To: | Cygwin Developers <cygwin-developers AT cygwin DOT com> |
Subject: | gcc static constructor multi-threading flaw |
Christopher (Faylor): 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. The reason for all this is that I sometimes get crashes in cygwin processes at program exit time because of corruption of atexit() internal data. Any multi-threaded Cygwin app is going to risk this problem. There are currently 4 such objects in cygwin1.dll itself. No idea how many there are when you count all the apps. Note that this is not a total fix. As I recall, the code generated by gcc is inherently not thread-safe -- it's testing a global to see whether to do the constructor/destructor code block, and there is a race condition. -- Joe Buehler
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |