Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes: > On Aug 15 14:53, Christopher Faylor wrote: > > On Sun, Aug 15, 2010 at 07:42:01PM +0200, Jason Curl wrote: > > >Is it allowed to issue the fork() system call while not in the main > > >thread? When I read the OpenGroup specifications I don't seem to find > > >anything against allowing this. > > If I'm reading this correctly then "the stack" in this case is the stack > > associated with the main thread. Cygwin only duplicates the stack in > > the executing thread. In your example, env (or presumably env2) from > > the main thread is passed to another thread which then calls fork. In > > that scenario, the forked process is going to see garbage in env since > > the array has never been initialized. > I guess I'm missing something here. Here's an excerpt from the SUSv4 > fork man page: > > The fork() function shall create a new process. The new process (child > process) shall be an exact copy of the calling process (parent process) > except as detailed below: > > [...] > > o A process shall be created with a single thread. If a > multi-threaded process calls fork(), the new process shall contain > a replica of the calling thread and its entire address space, > possibly including the states of mutexes and other resources. > [...] > > Is the stack of another thread, which is not executed in the forked > process anymore, a part of the calling's thread "entire address space"?
Open Group Posix.1c-2004 mentions only a "signal stack" doesn't need to be copied for XSI. Linux & FreeBSD 7.0 work OK. QNX641 returns ENOSYS if it even sniffs a thread call. I haven't tested Solaris Sparc. Which standard is Cygwin "closest" to, that I can use as a reference when I trip up on similar problems? I have the hint the SuSv4 implementation of Posix. Thanks for your wonderful support. Jason. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple