This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

python and threads. (was pthreads update)

----- Original Message -----
From: "Christopher Faylor" <>
To: <>
Sent: Monday, April 16, 2001 12:25 PM
Subject: Re: fork expert needed: (was Re: pthreads update for the

> 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
> >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
> 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
> than the parent.  It is allowed to do this.  Cygwin relies on a
> undocumented predictability to make fork work.  We try to augment
> in the DLL loading but there is no guarantee that it will be
> 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
> 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.


> cgf
> --
> Want to unsubscribe from this list?
> Check out:

Want to unsubscribe from this list?
Check out:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]