This is the mail archive of the cygwin@cygwin.com 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]

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


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