[M3devel] cvsup

[Jay K]

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/43941ed8/attachment-0002.html>