[M3devel] fork/cvsup

[Jay K]

Exec what?

You'd have to change the code to carefully reach the same place.

 

 - Jay
 


Subject: Re: [M3devel] fork/cvsup
From: hosking at cs.purdue.edu
Date: Wed, 17 Mar 2010 09:28:14 -0400
CC: m3devel at elegosoft.com
To: jay.krell at cornell.edu




Why not just exec in the child?


On 17 Mar 2010, at 03:47, Jay K wrote:

http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/man2/fork.2.html
 
 
There are limits to what you can do in the child process.  To be totally safe you should restrict your-self yourself
     self to only executing async-signal safe operations until such time as one of the exec functions is
     called.  All APIs, including global data symbols, in any framework or library should be assumed to be
     unsafe after a fork() unless explicitly documented to be safe or async-signal safe.  If you need to use
     these frameworks in the child process, you must exec.  In this situation it is reasonable to exec your-self. yourself.
     self.

 
http://www.opengroup.org/onlinepubs/000095399/functions/fork.html
 
Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of theexec functions is called. [THR]   Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. 
 
 
I've run through a few theories so far.
Current thinking is related to what Tony said:
 use pthread_atfork: 
   in prepare, stopworld 
   in parent, resumeworld 
   You don't want the child to be mid-gc for example, on another thread. Or mid-anything.
   in child, reinitialize -- current thread is the only thread
 
 
Also in the cvsup code, ShutDown should just call DoShutDown immediately.
I did that, without m3core changes, and it hits an error in the pthread code, signaling a nonexistant thread.
pthread_atfork/child should address that -- child shouldn't retain a record of all the threads in the parent.
 
 
I don't have a theory as to why user threads work.
 
 
I experimented with malloc vs. static alloc vs. sbrk vs. mmap(private) vs. mmap(shared).
I was expecting more cases to act like mmap(shared), but none did, only it.
 
 
I experimented with having mutexes and condition variables be initialize up front instead of on-demand.
Via changing cvsup to lock/unlock or broadcast immediately upon creating them.
On the theory that might let them work across process.
That didn't make a difference.
 
 
 - Jay

 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100317/c1a394dd/attachment-0002.html>