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