<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
Olaf, also search the web for fork1, forkall. Solaris has them.<BR>
You were right for Modula-3 user threads.<BR>
But not for Win32 or pthreads.<BR>
<BR>
<BR>
I tried something by accident..and it seemed to work.<BR>
In my attempts to write PThread.ForkAll, which would fork() and then in the child<BR>
initialize and recreate the threads of the parent (except for the current thread),<BR>
I commented<BR>
out the actual creating, leaving in the initialization..it oddly, it worked.<BR>
I probably had the "ShutDown" hack in cvsup (direct call instead of<BR>
through the cvsup dispatcher).<BR>
<BR>
<BR>
Perhaps this works because my cvsup test case is too small and<BR>
doesn't require its other threads.<BR>
Or maybe it suffices.<BR>
<BR>
<BR>
Still, there are two approaches to a fix. They are both not difficult.<BR>
<BR>
<BR>
One is to provide the overarching function: Thread.ForkAll().<BR>
Cvsup would just call that instead of Unix.fork.<BR>
<BR>
<BR>
The other is to provide pthread_atfork wrapper, use it internally a little bit,<BR>
and have cvsup use it as well to recreate its threads.<BR>
But I'm not sure it needs to.<BR>
<BR>
<BR>
Modula-3 wouldn't actually have to recreate any threads, just<BR>
set the booleans in RTCollector to false indicating they haven't been created.<BR>
<BR>
<BR>
Could be that cvsup doesn't require any/many threads to flow<BR>
from server to forked server, maybe just the one that it tears<BR>
down right away.<BR>
<BR>
<BR>
- Jay<BR> <BR>> Date: Wed, 17 Mar 2010 12:28:50 +0100<BR>> From: wagner@elegosoft.com<BR>> To: jay.krell@cornell.edu<BR>> CC: m3devel@elegosoft.com<BR>> Subject: RE: [M3devel] cvsup<BR>> <BR>> Quoting Jay K <jay.krell@cornell.edu>:<BR>> <BR>> > Here's a shorter more direct version.<BR>> ><BR>> > Please start here:<BR>> > http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html<BR>> > "There are at least two serious problems with the semantics of <BR>> > fork() in a multi-threaded program"<BR>> ><BR>> > I have a good theory as to the problem and the fix.<BR>> ><BR>> > Problem:<BR>> ><BR>> > With user threads, when you fork(), all the threads keep running in <BR>> > the new child.<BR>> ><BR>> > Because the data that causes them to exist is carried forward.<BR>> ><BR>> > With kernel threads, they don't, just the caller of fork().<BR>> <BR>> This is where I seem to have been wrong. I always thought that fork()<BR>> would indeed duplicate all threads and their execution states.<BR>> <BR>> > Fix:<BR>> ><BR>> > A few small uses of pthread_atfork both in m3core and cvsup.<BR>> ><BR>> > Abstracted behind Thread.PThreadAtFork that does nothing for user <BR>> > threads and Win32.<BR>> ><BR>> > They would do things like "reinitialize globals" and "recreate <BR>> > worker threads".<BR>> <BR>> This sounds reasonable, but is of course not trivial.<BR>> I think we should at least guarantee that the M3 runtime threads<BR>> that were running are available again and will do their work.<BR>> <BR>> I'm not sure if cvsupd itself will need application extensions, or if<BR>> the threads handling the streaming protocol are created after the fork.<BR>> <BR>> John Polstra used to be on this list and may be able to help.<BR>> <BR>> Olaf<BR>> -- <BR>> Olaf Wagner -- elego Software Solutions GmbH<BR>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<BR>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<BR>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<BR>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<BR>> <BR> </body>
</html>