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
Message-ID: <01dd01c0c628$974225a0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
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> <20010415222520 DOT E10309 AT redhat DOT com>
Subject: python and threads. (was pthreads update)
Date: Mon, 16 Apr 2001 13:51:58 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 16 Apr 2001 03:44:41.0439 (UTC) FILETIME=[918DD6F0:01C0C627]

----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Monday, April 16, 2001 12:25 PM
Subject: Re: fork expert needed: (was Re: pthreads update for the
adventurous)


> On Mon, Apr 16, 2001 at 11:19:46AM +1000, Robert Collins wrote:
> >I've reread DLL initialisation stuff.
> >
> >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.

Right.,

> 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.

Yes exactly. Thats the bit I'm wondering about: what could be different
in the child because the parent program is multi-threaded. Things like a
race in the recorded dll order.... I'm still drawing a blank :[

> >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.

Sorry - I knew the function call. What I'm drawing a blank on is how
setjmp stuff works. The control sequence is a little ... strange. Anyway
that should be mostly irrelevant.

Jason: Can you look into the testcases, perhaps stripping them down to
bare basics that fail the same way? Ideally we can isolate the
circumstances to something usefully debugged.

Rob

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


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