[M3devel] cvsup

[Jay K]

For that matter, we can just provide Thread.ForkAll.

  special implementation on pthreads.

  Just call Unix.fork() on user threads.

  No implementation for Win32.

 

 - Jay

 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Date: Wed, 17 Mar 2010 11:02:02 +0000
Subject: Re: [M3devel] cvsup



Another good option might be
"RecreateThreadsAfterFork()"
 
that cvsup can call. I'm trying that.
If that doesn't work, I'll track down all of cvsup's thread creates.
 
 - Jay
 


From: jay.krell at cornell.edu
To: wagner at elegosoft.com; m3devel at elegosoft.com
Date: Wed, 17 Mar 2010 10:50:31 +0000
Subject: Re: [M3devel] cvsup



Here's a shorter more direct version.


Please start here:
http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html
  "There are at least two serious problems with the semantics of fork() in a multi-threaded program"

 
I have a good theory as to the problem and the fix.
 
 
Problem:
 
With user threads, when you fork(), all the threads keep running in the new child.
   Because the data that causes them to exist is carried forward.
 
 
With kernel threads, they don't, just the caller of fork().
 
 
Fix:
  A few small uses of pthread_atfork both in m3core and cvsup.
  Abstracted behind Thread.PThreadAtFork that does nothing for user threads and Win32.
  They would do things like "reinitialize globals" and "recreate worker threads".
 
 
You can't just call all the module initializers over.
That would ultimately I believe reset too much data.
   ?
 
 
It might be possible, though, to setjmp, run the module initializers, longjmp.
Something like, perhaps, a flag to RTLinker.InitRuntime that causes it to
longjmp instead of calling main. However this would still e.g. give the initial thread
the wrong stackbase and mess up garbage collection.
 
 
I'm much more keen on selective use of pthread_atfork, in m3core and cvsup.
 
 
A more conventional approach is the program to rerun itself with some flags
that "push" it fast to "resume" point, but that somewhat defeats the
purpose of the fork + do work model -- cheap reuse of already established state.
 
 
Lingering problem:
  Any libraries that create worker threads need to use Thread.PThreadAtFork in order to be compatible with the fork + do more work pattern.
 
 
fork + exec is fine.
 
 
 - Jay
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100317/2d42f91e/attachment-0002.html>