<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
<pre> > Especially the different behaviours of fork for user and pthreads</pre><br>The behavior has been unified. User threads no longer survive fork.<br>Except perhaps on FreeBSD 5? (Off by one somewhere in the discussion!)<br>It looks like it is ok on FreeBSD 6.<br>I think we could fix it on FreeBSD 5. At least if we changed all of our fork() to be RTProcess.Fork()<br>and called the handlers in there, at least on FreeBSD 5.<br>I believe the difference is only noticable if you fork-and-do-work.<br>Not if you fork-and-exec.<br>I am very tempted to fix this, so that nobody would be discussing where it did or didn't work.<br>(Though, fork() would still vary in behavior, but we'd never use it directly..)<br><br><br>Threads not surviving fork is new with using pthreads.<br>Threads never survived fork on Windows.<br>For user threads, the change was a bit late, didn't occur until we worked on getting cvsupd to work with pthreads.<br>
<br><br> - Jay<br><br><br>> Date: Sat, 12 Feb 2011 13:02:11 +0100<br>> From: wagner@elegosoft.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] pthread_atfork<br>> <br>> I think it would be acceptable to say that pthread threading is<br>> broken on FreeBSD6 (as it is not officially supported any more).<br>> All the stuff below should be documented in the 'known problems'<br>> section. Especially the different behaviours of fork for<br>> user and pthreads. This should also be mentioned in the M3<br>> interfaces (source code)!<br>> <br>> Also that to use use threads with FreeBSD requires to remove the<br>> -pthread flag, as Mika noted.<br>> <br>> BTW, do we have a chapter explaining what to do to use user threads<br>> instead of the default pthreads?<br>> <br>> Olaf<br>> <br>> PS: Hint: this would be a great task for anybody lurking on the lists<br>> and trying to get involved :-)<br>> <br>> Quoting Jay K <jay.krell@cornell.edu>:<br>> <br>> ><br>> > I wrote that.<br>> ><br>> > As I recall, FreeBSD < 6 doesn't have pthread_atfork.<br>> ><br>> > I think that was based on reading the man pages.<br>> ><br>> > So, yes. What would you suggest?<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > All this atfork stuff came about as part of getting cvsupd to work.<br>> ><br>> > With pthreads/kernel threads. It historically worked, with <br>> > Modula-3 user threads.<br>> ><br>> > Modula-3 user threads have this funny property that all threads <br>> > survive work.<br>> ><br>> > With pthreads/kernel threads, fork gives you a new process with <br>> > just one thread.<br>> ><br>> > (Solaris has fork1 and forkall, and fork maybe used to be <br>> > forkall, but now it is fork1).<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > cvsupd is one of those slightly unusual programs that does "fork and <br>> > then do more work"<br>> ><br>> > as supposed to the more typical "fork and exec".<br>> ><br>> ><br>> ><br>> > Which is to say..I don't know. Maybe, don't expect pthreads to work <br>> > on FreeBSD < 6?<br>> ><br>> > At least not in a process that ever calls fork? Or does "fork and <br>> > then more work"?<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > In reality, i think a lot of libraries have trouble with "fork and <br>> > then do more work", but<br>> ><br>> > I don't know. I recall vague notices in the Apple/Darwin manpages <br>> > not to assume<br>> ><br>> > this works -- the obvious implication that there is plenty of use of <br>> > pthreads e.g. mutexes,<br>> ><br>> > but relatively little use of pthread_atfork.<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > You could perhaps replace all uses of fork with a function that <br>> > called the fork handlers,<br>> ><br>> > then fork, then the other handlers. That is probably what I meant in <br>> > the comment<br>> ><br>> > about this being easy to fix.<br>> ><br>> > You might though then run into the problem that callers of fork can't do much<br>> ><br>> > before exec...oh, that's vfork I bet actually.<br>> ><br>> ><br>> ><br>> ><br>> ><br>> > - Jay<br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> >> To: hosking@cs.purdue.edu<br>> >> Date: Fri, 11 Feb 2011 19:05:25 -0800<br>> >> From: mika@async.caltech.edu<br>> >> CC: m3devel@elegosoft.com; jay.krell@cornell.edu<br>> >> Subject: [M3devel] pthread_atfork<br>> >><br>> >> Tony,<br>> >><br>> >> What's RTProcessC.c doing?<br>> >><br>> >> I note the following cryptic comment:<br>> >><br>> >> /* NOTE: Even userthreads now depends<br>> >> * on availability of pthreads.<br>> >> * This can be fixed if need be.<br>> >> */<br>> >><br>> >> now further down we can read:<br>> >><br>> >> #if defined(_WIN32) \<br>> >> || defined(__vms) \<br>> >> || (defined(__FreeBSD__) && (__FreeBSD__ < 6))<br>> >> return 0;<br>> >> #else<br>> >> while (1)<br>> >> {<br>> >> int i = pthread_atfork(prepare, parent, child);<br>> >> if (i != EAGAIN)<br>> >> return i;<br>> >> sleep(0);<br>> >> }<br>> >> #endif<br>> >><br>> >> so on FreeBSD 5 (what I'm running on my "FreeBSD4" system),<br>> >> RTProcess.RegisterForkHandlers does nothing?<br>> >><br>> >> Hmmm.....<br>> >><br>> >> Mika<br>> ><br>> <br>> <br>> <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>