Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Date: Sun, 15 Apr 2001 22:25:20 -0400
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: fork expert needed: (was Re: pthreads update for the adventurous)
Message-ID: <20010415222520.E10309@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <037701c0c3ab$9049bf30$0200a8c0 AT lifelesswks> <20010413221222 DOT C5606 AT dothill DOT com> <006001c0c4af$179b79c0$0200a8c0 AT lifelesswks> <20010414223139 DOT A906 AT redhat DOT com> <001701c0c557$02a861b0$0200a8c0 AT lifelesswks> <20010415090600 DOT A8359 AT redhat DOT com> <001301c0c5af$9cb7e520$0200a8c0 AT lifelesswks> <20010415153317 DOT C9015 AT redhat DOT com> <013b01c0c613$53cdac00$0200a8c0 AT lifelesswks>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.11i
In-Reply-To: <013b01c0c613$53cdac00$0200a8c0@lifelesswks>; from robert.collins@itdomain.com.au on Mon, Apr 16, 2001 at 11:19:46AM +1000

On Mon, Apr 16, 2001 at 11:19:46AM +1000, Robert Collins wrote:
>I've reread DLL initialisation stuff.
>
>The fork_child function is not a DLL entry point for cygwin1.dll.

Didn't claim that it was.  I was talking about the initialization
section of the loaded DLLs.

>Also while MSDN states that only one thread at a time can call the
>entry point function, it does not state or imply that other threads are
>suspended during that process.

Ok, I reluctantly stand corrected.  I thought that both the MSDN and
my own personal experience (waiting for a signal from Cygwi's signal
thread that never arrived) said this.  I couldn't find any reference
to this, though.

However, it doesn't matter.  In the context of the child, only one
thread is running.

In the parent, you're right.  Another thread could be running,
allocating memory and doing all sorts of nasty stuff, which could screw
up the child's attempt to duplicate the parent's state.  I sincerely
doubt that this is what would cause this behavior, though.

It seems likely that the forked child just organized memory differently
than the parent.  It is allowed to do this.  Cygwin relies on a certain
undocumented predictability to make fork work.  We try to augment things
in the DLL loading but there is no guarantee that it will be successful.

Sometimes there is memory occupying the space where you want to load
a DLL and there's not much that you can do about it.

I just looked at the initialization code again.  I was wrong when I said
that the DLL relocation happens during the call to DLL initialization.
That clearly is impossible.  You can't have a DLL relocate itself.

It does happen during *Cygwin* DLL initialization, though.  And by
"Cygwin DLL initialization" I mean that it happens when Cygwin is
initializing DLLs that it knows about.  I do not mean that it happens
during the initialization of the Cygwin DLL itself.

>Mind you as I don't know understand how you create the new pid during
>fork I'm still going blind here.

The new pid is created by CreateProcess.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple