Mail Archives: cygwin/2001/04/15/21:20:22
----- Original Message -----
From: "Christopher Faylor" <cgf AT redhat DOT com>
To: <cygwin AT cygwin DOT com>
Sent: Monday, April 16, 2001 5:33 AM
Subject: Re: fork expert needed: (was Re: pthreads update for the
adventurous)
> On Sun, Apr 15, 2001 at 11:25:58PM +1000, Robert Collins wrote:
> >
> >
> >----- Original Message -----
> >From: "Christopher Faylor" <cgf AT redhat DOT com>
> >To: <cygwin AT cygwin DOT com>
> >Sent: Sunday, April 15, 2001 11:06 PM
> >Subject: Re: fork expert needed: (was Re: pthreads update for the
> >adventurous)
> >
> >
> >> On Sun, Apr 15, 2001 at 12:51:44PM +1000, Robert Collins wrote:
> >>>>I added this dll relocation stuff last year to help with perl. It
> >>>>wasn't fun.
> >>>
> >>>Oh. Well I infer that it only occurs with threads enabled in
python,
> >>>or Jason wouldn't be telling us. Any hints Chris for possible
> >>>races/locks that might prevent the child doing the relocation if
the
> >>>parent has active threads ?
> >>
> >>I believe the relocation happens during DLL initialization when all
> >>other threads are suspended.
> >>
> >>cgf
> >>
> >
> >fork() doesn't suspend all the threads in the parent. The thread
doing
> >the call blocks, and the child is started with only one thread. I
> >don't believe all the threads are meant to be suspended under posix
> >threads either - but I'll look into this.
>
> Let me say this again:
>
> "I believe the relocation happens during DLL initialization when all
> other threads are suspended."
>
> Please read up on MSDN on what happens during DLL initialization with
> threads and stuff. This isn't a Cygwin thing, it's a windows thing.
>
> cgf
>
I've reread DLL initialisation stuff.
The fork_child function is not a DLL entry point for cygwin1.dll. 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.
Finally dll_list::load_after_fork calls LoadLibraryEx which dll entry
point functions are not allowed to call.
Mind you as I don't know understand how you create the new pid during
fork I'm still going blind here.
I don't have time to do anything indepth today, but I hope to get time
later in the week . My testcase will be to
compile cygwin with DEBUGGING and set a fork delay of 5 seconds.
write a test prog that
a) starts a new thread that writes "1\n" "2\n" etc via printf.
b) forks from the main thread.
if the 1\n2\n3\n.. pause then cygwin may have an internal mutex on
system functions, and I'll do a second case using win32 only functions
in the second thread.
If as I suspect the 1\n2\n3\n don't pause the point is demonstrated..
Rob
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -