This is the mail archive of the
mailing list for the Cygwin project.
python and threads. (was pthreads update)
----- Original Message -----
From: "Christopher Faylor" <firstname.lastname@example.org>
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.
> 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