[M3devel] pthread_atfork

[Mika Nystrom]

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