delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/1999/12/21/16:52:17

Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Tue, 21 Dec 1999 16:51:52 -0500
To: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
Cc: cygwin AT sourceware DOT cygnus DOT com
Subject: Re: SUMMARY: Known issues with gnuwin32 development tools of year 1999
Message-ID: <19991221165152.A11739@cygnus.com>
Mail-Followup-To: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>,
cygwin AT sourceware DOT cygnus DOT com
References: <19991221152811 DOT A5107 AT cygnus DOT com> <199912212035 DOT OAA10928 AT hp2 DOT xraylith DOT wisc DOT edu>
Mime-Version: 1.0
X-Mailer: Mutt 1.0i
In-Reply-To: <199912212035.OAA10928@hp2.xraylith.wisc.edu>; from khan@NanoTech.Wisc.EDU on Tue, Dec 21, 1999 at 02:35:10PM -0600

On Tue, Dec 21, 1999 at 02:35:10PM -0600, Mumit Khan wrote:
>[ Only following up in Cygwin mailing list ]
>
>Chris Faylor <cgf AT cygnus DOT com> writes:
>
>> Just to add a little bit more info, Mumit submitted a patch which
>> probably will fix the problem but the patch uses malloc for temporary
>> storage.  I've recently been bitten by the use of malloc in
>> initialization code so I've been futilely trying to think of some way
>> around this.  It's probable that Mumit's use of malloc won't really
>> cause a problem but I'd like to avoid it if I can, so I've been letting
>> this simmer in my unconscious mind for a while to see if it comes up
>> with something interesting.
>
>Before I forget, I do have a patch that uses malloc for dynamic loading,
>but keeps event-based synchronization for the "normal", ie., link-time 
>loading. Is that acceptable? If so, I'll dig it out ... 
>
>With this, you can let it simmer while allowing both static and dynamic 
>loading to work ;-)

Actually, it might be but I don't really know.  The specific problem
manifests during fork.  Since fork overwrites the heap, you can't
rely on mallocing anything until after fork returns.

In the case of dynamic loading we probably are ok but since this has
bitten me once, I'm assuming that with a small tweak here or there
it could bite us again and then we'd be scratching our heads over
this again in a few months.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019