[M3devel] cvsup

[Jay K]

Olaf, also search the web for fork1, forkall. Solaris has them.

You were right for Modula-3 user threads.

But not for Win32 or pthreads.

 

 

I tried something by accident..and it seemed to work.

In my attempts to write PThread.ForkAll, which would fork() and then in the child

initialize and recreate the threads of the parent (except for the current thread),

I commented

out the actual creating, leaving in the initialization..it oddly, it worked.

I probably had the "ShutDown" hack in cvsup (direct call instead of

through the cvsup dispatcher).

 

 

Perhaps this works because my cvsup test case is too small and

doesn't require its other threads.

Or maybe it suffices.

 

 

Still, there are two approaches to a fix. They are both not difficult.

 

 

One is to provide the overarching function: Thread.ForkAll().

Cvsup would just call that instead of Unix.fork.

 

 

The other is to provide pthread_atfork wrapper, use it internally a little bit,

and have cvsup use it as well to recreate its threads.

  But I'm not sure it needs to.

 

 

Modula-3 wouldn't actually have to recreate any threads, just

set the booleans in RTCollector to false indicating they haven't been created.

 

 

Could be that cvsup doesn't require any/many threads to flow

from server to forked server, maybe just the one that it tears

down right away.

 

 

 - Jay
 
> Date: Wed, 17 Mar 2010 12:28:50 +0100
> From: wagner at elegosoft.com
> To: jay.krell at cornell.edu
> CC: m3devel at elegosoft.com
> Subject: RE: [M3devel] cvsup
> 
> Quoting Jay K <jay.krell at cornell.edu>:
> 
> > 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().
> 
> This is where I seem to have been wrong. I always thought that fork()
> would indeed duplicate all threads and their execution states.
> 
> > 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".
> 
> This sounds reasonable, but is of course not trivial.
> I think we should at least guarantee that the M3 runtime threads
> that were running are available again and will do their work.
> 
> I'm not sure if cvsupd itself will need application extensions, or if
> the threads handling the streaming protocol are created after the fork.
> 
> John Polstra used to be on this list and may be able to help.
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95
> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100317/0e7a3cee/attachment-0002.html>