[M3devel] pthread_atfork

[Jay K]

 > Especially the different behaviours of fork for user and pthreads
The behavior has been unified. User threads no longer survive fork.
Except perhaps on FreeBSD 5? (Off by one somewhere in the discussion!)
It looks like it is ok on FreeBSD 6.
I think we could fix it on FreeBSD 5. At least if we changed all of our fork() to be RTProcess.Fork()
and called the handlers in there, at least on FreeBSD 5.
I believe the difference is only noticable if you fork-and-do-work.
Not if you fork-and-exec.
I am very tempted to fix this, so that nobody would be discussing where it did or didn't work.
(Though, fork() would still vary in behavior, but we'd never use it directly..)


Threads not surviving fork is new with using pthreads.
Threads never survived fork on Windows.
For user threads, the change was a bit late, didn't occur until we worked on getting cvsupd to work with pthreads.



 - Jay


> Date: Sat, 12 Feb 2011 13:02:11 +0100
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] pthread_atfork
> 
> 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
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110212/5fe65fa8/attachment-0002.html>