<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Tahoma
}
--></style>
</head>
<body class='hmmessage'>
I wrote that.<br>
As I recall, FreeBSD < 6 doesn't have pthread_atfork.<br>
I think that was based on reading the man pages.<br>
So, yes. What would you suggest?<br>
<br>
<br>
All this atfork stuff came about as part of getting cvsupd to work.<br>
With pthreads/kernel threads. It historically worked, with Modula-3 user threads.<br>
Modula-3 user threads have this funny property that all threads survive work.<br>
With pthreads/kernel threads, fork gives you a new process with just one thread.<br>
(Solaris has fork1 and forkall, and fork maybe used to be forkall, but now it is fork1).<br>
<br>
<br>
cvsupd is one of those slightly unusual programs that does "fork and then do more work"<br>
as supposed to the more typical "fork and exec".<br>
<br>
Which is to say..I don't know. Maybe, don't expect pthreads to work on FreeBSD < 6?<br>
At least not in a process that ever calls fork? Or does "fork and then more work"?<br>
<br>
<br>
In reality, i think a lot of libraries have trouble with "fork and then do more work", but<br>
I don't know. I recall vague notices in the Apple/Darwin manpages not to assume<br>
this works -- the obvious implication that there is plenty of use of pthreads e.g. mutexes,<br>
but relatively little use of pthread_atfork.<br>
<br>
<br>
You could perhaps replace all uses of fork with a function that called the fork handlers,<br>
then fork, then the other handlers. That is probably what I meant in the comment<br>
about this being easy to fix.<br>
You might though then run into the problem that callers of fork can't do much<br>
before exec...oh, that's vfork I bet actually.<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> </body>
</html>