[M3devel] pthread_atfork

[Olaf Wagner]

Well, I think actually the fork-and-do-work pattern has been
the default for a long time with the M3 user threads implementation.
It wasn't specified though, and I think no application except
CVSup did use it.

Jay is not responsible for any breakage here, he just tried to fix
CVSup and establish a consistent behaviour after our change to
system pthreads on most platforms.

Olaf

Quoting Mika Nystrom <mika at async.caltech.edu>:

> Hi Jay,
>
> I think "fork and do work" qualifies as a bug in the application, if
> the application wants to be portable.  Why can't it fork and exec instead?
> If it wants to do more work it should just fork and exec another copy
> of itself.
>
> fork() is also not part of Modula-3...  Process.Create() is, however.
> Don't tell me you broke that as part of "fixing" things for cvsupd...
>
> There is still one aspect of your comment I don't understand.  What does
> the call to pthread_atfork actually accomplish when running with user
> threads?  You say below that "don't expect pthreads to work on FreeBSD <
> 6 [using the fork-and-do-work pattern]".  Fair enough.  But why would
> user threads work?  We're skipping pthread_atfork for them too.
>
> Do we not need pthread_atfork with user threads?  What you're saying
> suggests that FreeBSD >= 6 and all other platforms need pthread_atfork
> with user threads.  Is that really what you mean?
>
> At the moment I'm just concerned with getting user threads to work as
> I know there are bugs with pthreads.
>
> I also think we should not waste time and effort making the "fork and do
> work" pattern work unless it's really, really necessary (which I really
> don't see why it would be).  Fix the application instead of introducing
> bugs in the libraries and language implementation!
>
> I've been trying for a long, long time to switch from PM3 to CM3 (almost
> ten years, I think).  These bugs from "enhancements" have stopped me
> every time.  Maybe things are finally working well enough...
>
> (some comments inline in your quoted text below)
>
>      Mika
>
>
> Jay K writes:
>> --_19a7daf7-3f48-43cb-bea8-6f0fa13b0fef_
>> Content-Type: text/plain; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>>
>>
>> I wrote that.
>>
>> As I recall=2C FreeBSD < 6 doesn't have pthread_atfork.
>>
>> I think that was based on reading the man pages.
>>
>> So=2C yes. What would you suggest?
>>
>>
>>
>>
>>
>> All this atfork stuff came about as part of getting cvsupd to work.
>>
>>  With pthreads/kernel threads. It historically worked=2C with Modula-3 use=
>> r threads.
>>
>>  Modula-3 user threads have this funny property that all threads survive w=
>> ork.
>
> you mean survive fork don't you?
>
>>
>>  With pthreads/kernel threads=2C fork gives you a new process with just on=
>> e thread.
>>
>>   (Solaris has fork1 and forkall=2C and fork maybe used to be forkall=2C b=
>> ut now it is fork1).
>>
>>
>>
>>
>>
>> cvsupd is one of those slightly unusual programs that does "fork and then d=
>> o more work"
>>
>> as supposed to the more typical "fork and exec".
>>
>>
>>
>> Which is to say..I don't know. Maybe=2C don't expect pthreads to work on Fr=
>> eeBSD < 6?
>>
>> At least not in a process that ever calls fork? Or does "fork and then more=
>> work"?
>>
>>
>>
>>
>>
>> In reality=2C i think a lot of libraries have trouble with "fork and then d=
>> o more work"=2C but
>>
>> I don't know. I recall vague notices in the Apple/Darwin manpages not to as=
>> sume
>>
>> this works -- the obvious implication that there is plenty of use of pthrea=
>> ds e.g. mutexes=2C
>>
>> but relatively little use of pthread_atfork.
>>
>>
>>
>>
>>
>> You could perhaps replace all uses of fork with a function that called the =
>> fork handlers=2C
>>
>> then fork=2C then the other handlers. That is probably what I meant in the =
>> comment
>>
>> about this being easy to fix.
>>
>> You might though then run into the problem that callers of fork can't do mu=
>> ch
>>
>> before exec...oh=2C that's vfork I bet actually.
>
> I don't understand this paragraph either :(
>
>>
>>
>>
>>
>>
>> - Jay
>>
>>
>>
>>
>>
>>
>>> To: hosking at cs.purdue.edu
>>> Date: Fri=2C 11 Feb 2011 19:05:25 -0800
>>> From: mika at async.caltech.edu
>>> CC: m3devel at elegosoft.com=3B jay.krell at cornell.edu
>>> Subject: [M3devel] pthread_atfork
>>> =20
>>> Tony=2C
>>> =20
>>> What's RTProcessC.c doing?
>>> =20
>>> I note the following cryptic comment:
>>> =20
>>> /* NOTE: Even userthreads now depends
>>>  * on availability of pthreads.
>>>  * This can be fixed if need be.
>>>  */
>>> =20
>>> now further down we can read:
>>> =20
>>> #if defined(_WIN32) \
>>>         || defined(__vms) \
>>>         || (defined(__FreeBSD__) && (__FreeBSD__ < 6))
>>>     return 0=3B
>>> #else
>>>     while (1)
>>>     {
>>>       int i =3D pthread_atfork(prepare=2C parent=2C child)=3B
>>>       if (i !=3D EAGAIN)
>>>         return i=3B
>>>       sleep(0)=3B
>>>     }
>>> #endif
>>> =20
>>> so on FreeBSD 5 (what I'm running on my "FreeBSD4" system)=2C
>>> RTProcess.RegisterForkHandlers does nothing?
>>> =20
>>> Hmmm.....
>>> =20
>>>     Mika
>> 		 	   		  =
>>
>> --_19a7daf7-3f48-43cb-bea8-6f0fa13b0fef_
>> Content-Type: text/html; charset="iso-8859-1"
>> Content-Transfer-Encoding: quoted-printable
>>
>> <html>
>> <head>
>> <style><!--
>> .hmmessage P
>> {
>> margin:0px=3B
>> padding:0px
>> }
>> body.hmmessage
>> {
>> font-size: 10pt=3B
>> font-family:Tahoma
>> }
>> --></style>
>> </head>
>> <body class=3D'hmmessage'>
>> I wrote that.<br>
>> As I recall=2C FreeBSD &lt=3B 6 doesn't have pthread_atfork.<br>
>> I think that was based on reading the man pages.<br>
>> So=2C yes. What would you suggest?<br>
>> <br>
>> <br>
>> All this atfork stuff came about as part of getting cvsupd to work.<br>
>> &nbsp=3B With pthreads/kernel threads. It historically worked=2C with Modul=
>> a-3 user threads.<br>
>> &nbsp=3B Modula-3 user threads have this funny property that all threads su=
>> rvive work.<br>
>> &nbsp=3B With pthreads/kernel threads=2C fork gives you a new process with =
>> just one thread.<br>
>> &nbsp=3B&nbsp=3B (Solaris has fork1 and forkall=2C and fork maybe used to b=
>> e forkall=2C but now it is fork1).<br>
>> <br>
>> <br>
>> cvsupd is one of those slightly unusual programs that does "fork and then d=
>> o more work"<br>
>> as supposed to the more typical "fork and exec".<br>
>> <br>
>> Which is to say..I don't know. Maybe=2C don't expect pthreads to work on Fr=
>> eeBSD &lt=3B 6?<br>
>> At least not in a process that ever calls fork? Or does "fork and then more=
>> work"?<br>
>> <br>
>> <br>
>> In reality=2C i think a lot of libraries have trouble with "fork and then d=
>> o more work"=2C but<br>
>> I don't know. I recall vague notices in the Apple/Darwin manpages not to as=
>> sume<br>
>> this works -- the obvious implication that there is plenty of use of pthrea=
>> ds e.g. mutexes=2C<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=2C<br>
>> then fork=2C 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 mu=
>> ch<br>
>> before exec...oh=2C that's vfork I bet actually.<br>
>> <br>
>> <br>
>> &nbsp=3B- Jay<br><br><br><br><br><br><br>&gt=3B To: hosking at cs.purdue.edu<b=
>> r>&gt=3B Date: Fri=2C 11 Feb 2011 19:05:25 -0800<br>&gt=3B From: mika at async=
>> .caltech.edu<br>&gt=3B CC: m3devel at elegosoft.com=3B jay.krell at cornell.edu<b=
>> r>&gt=3B Subject: [M3devel] pthread_atfork<br>&gt=3B <br>&gt=3B Tony=2C<br>=
>> &gt=3B <br>&gt=3B What's RTProcessC.c doing?<br>&gt=3B <br>&gt=3B I note th=
>> e following cryptic comment:<br>&gt=3B <br>&gt=3B /* NOTE: Even userthreads=
>> now depends<br>&gt=3B  * on availability of pthreads.<br>&gt=3B  * This ca=
>> n be fixed if need be.<br>&gt=3B  */<br>&gt=3B <br>&gt=3B now further down =
>> we can read:<br>&gt=3B <br>&gt=3B #if defined(_WIN32) \<br>&gt=3B         |=
>> | defined(__vms) \<br>&gt=3B         || (defined(__FreeBSD__) &amp=3B&amp=
>> =3B (__FreeBSD__ &lt=3B 6))<br>&gt=3B     return 0=3B<br>&gt=3B #else<br>&g=
>> t=3B     while (1)<br>&gt=3B     {<br>&gt=3B       int i =3D pthread_atfork=
>> (prepare=2C parent=2C child)=3B<br>&gt=3B       if (i !=3D EAGAIN)<br>&gt=
>> =3B         return i=3B<br>&gt=3B       sleep(0)=3B<br>&gt=3B     }<br>&gt=
>> =3B #endif<br>&gt=3B <br>&gt=3B so on FreeBSD 5 (what I'm running on my "Fr=
>> eeBSD4" system)=2C<br>&gt=3B RTProcess.RegisterForkHandlers does nothing?<b=
>> r>&gt=3B <br>&gt=3B Hmmm.....<br>&gt=3B <br>&gt=3B     Mika<br>
>> 	 	   		  =
>> </body>
>> </html>=
>>
>> --_19a7daf7-3f48-43cb-bea8-6f0fa13b0fef_--
>



-- 
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