Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@sourceware.cygnus.com Delivered-To: mailing list cygwin@sourceware.cygnus.com Date: Tue, 21 Dec 1999 21:46:30 -0500 From: Chris Faylor To: Mumit Khan Cc: cygwin@sourceware.cygnus.com Subject: Re: SUMMARY: Known issues with gnuwin32 development tools of year 1999 Message-ID: <19991221214630.A27884@cygnus.com> Reply-To: cygwin@sourceware.cygnus.com Mail-Followup-To: Mumit Khan , cygwin@sourceware.cygnus.com References: <19991221165152.A11739@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from khan@NanoTech.Wisc.EDU on Tue, Dec 21, 1999 at 06:44:47PM -0600 On Tue, Dec 21, 1999 at 06:44:47PM -0600, Mumit Khan wrote: >On Tue, 21 Dec 1999, Chris Faylor wrote: >>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. > >I do understand your hesitation on this. > >However, fork will never work for dynamic loads -- the loading app will >get very confused at this, and I suspect the same for exec and popen as >well, so the problem is moot for dynamic loads. Hmm. You're right. In that case we should invalidate fork for dynamic loads. >My proposal still stands since it won't modify the behavior of cygwin >linked apps in any way, only change it for dynamic loads. I guess I'm being unduly cautious. Give me a couple of days and I'll probably check in your malloc change. cgf -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe@sourceware.cygnus.com