[M3devel] pthread_atfork

[Olaf Wagner]

I think it would be acceptable to say that pthread threading is
broken on FreeBSD6 (as it is not officially supported any more).
All the stuff below should be documented in the 'known problems'
section. Especially the different behaviours of fork for
user and pthreads. This should also be mentioned in the M3
interfaces (source code)!

Also that to use use threads with FreeBSD requires to remove the
-pthread flag, as Mika noted.

BTW, do we have a chapter explaining what to do to use user threads
instead of the default pthreads?

Olaf

PS: Hint: this would be a great task for anybody lurking on the lists
and trying to get involved :-)

Quoting Jay K <jay.krell at cornell.edu>:

>
> I wrote that.
>
> As I recall, FreeBSD < 6 doesn't have pthread_atfork.
>
> I think that was based on reading the man pages.
>
> So, 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, with   
> Modula-3 user threads.
>
>   Modula-3 user threads have this funny property that all threads   
> survive work.
>
>   With pthreads/kernel threads, fork gives you a new process with   
> just one thread.
>
>    (Solaris has fork1 and forkall, and fork maybe used to be   
> forkall, but now it is fork1).
>
>
>
>
>
> cvsupd is one of those slightly unusual programs that does "fork and  
>  then do more work"
>
> as supposed to the more typical "fork and exec".
>
>
>
> Which is to say..I don't know. Maybe, don't expect pthreads to work   
> on FreeBSD < 6?
>
> At least not in a process that ever calls fork? Or does "fork and   
> then more work"?
>
>
>
>
>
> In reality, i think a lot of libraries have trouble with "fork and   
> then do more work", but
>
> I don't know. I recall vague notices in the Apple/Darwin manpages   
> not to assume
>
> this works -- the obvious implication that there is plenty of use of  
>  pthreads e.g. mutexes,
>
> but relatively little use of pthread_atfork.
>
>
>
>
>
> You could perhaps replace all uses of fork with a function that   
> called the fork handlers,
>
> then fork, 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 much
>
> before exec...oh, that's vfork I bet actually.
>
>
>
>
>
>  - Jay
>
>
>
>
>
>
>> To: hosking at cs.purdue.edu
>> Date: Fri, 11 Feb 2011 19:05:25 -0800
>> From: mika at async.caltech.edu
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: [M3devel] pthread_atfork
>>
>> Tony,
>>
>> What's RTProcessC.c doing?
>>
>> I note the following cryptic comment:
>>
>> /* NOTE: Even userthreads now depends
>>  * on availability of pthreads.
>>  * This can be fixed if need be.
>>  */
>>
>> now further down we can read:
>>
>> #if defined(_WIN32) \
>>         || defined(__vms) \
>>         || (defined(__FreeBSD__) && (__FreeBSD__ < 6))
>>     return 0;
>> #else
>>     while (1)
>>     {
>>       int i = pthread_atfork(prepare, parent, child);
>>       if (i != EAGAIN)
>>         return i;
>>       sleep(0);
>>     }
>> #endif
>>
>> so on FreeBSD 5 (what I'm running on my "FreeBSD4" system),
>> RTProcess.RegisterForkHandlers does nothing?
>>
>> Hmmm.....
>>
>>     Mika
>



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