OS/X fork() officially broken?

[Andriy Syrovenko]

2012/10/4 James Peach <jorgar at gmail.com>

> On 3 October 2012 16:18, Matthieu Patou <mat at samba.org> wrote:
> > On 10/03/2012 12:24 PM, Jelmer Vernooij wrote:
> >>
> >> On Wed, 2012-10-03 at 12:04 -0700, Jeremy Allison wrote:
> >>>
> >>> On Wed, Oct 03, 2012 at 04:11:33PM +0200, Volker Lendecke wrote:
> >>>>
> >>>> Hi!
> >>>>
> >>>> Via the discussion thread on
> >>>> https://lwn.net/Articles/518306/ I found the link to the
> >>>> OS/X fork manpage:
> >>>>
> >>>>
> http://developer.apple.com/library/ios/#documentation/system/conceptual/manpages_iphoneos/man2/fork.2.html
> >>>>
> >>>> Despite the link pointing at ios, the text says it is the
> >>>> OS/X manpage for fork(2).
> >>>>
> >>>> Look at the CAVEATS section. That is likely one of the more
> >>>> technical reasons why Apple switched to something but Samba.
> >>>> For us it does not make any sense at all to even try to
> >>>> revive smbd on OS/X in its current architecture.
> >>>
> >>> Isn't that an iOS manpage, not an OS/X manpage ?
> >>
> >> It's a confusing location for it, but the header says Mac OS X. Another
> >> copy can be found here:
> >>
> >>
> >>
> https://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man2/fork.2.html
> >>
> >>> I can't believe they broke fork() so badly. It's a UNIX
> >>> after all..
> >>
> >> ... if you remove the shiny outside layers, and the plastering on top of
> >> what remains of the BSDish core. ;-)
> >
> > But as jim pointed it with mach kernel ipc for pretty a lot of things,
> but I
> > can't help thinking that this hasn't changes since a couple of years.
>
> Correct. The behaviour (and policy) has been the same forever. The
> only thing new here is the documentation.
>
> --
> James Peach | jorgar at gmail.com
>

Well, I've looked into that man page on my Lion, and found the the Caveats
section sounds very very familiar. It is actually the same restrictions ANY
modern *nix system places on a multi-threaded application calling fork().
In this case only that thread that the fork() has been called from survives
the fork() in the child process, the states of all synchronization objects
are unknown (including those from CRT), and the only system/stdlib calls
you can safely invoke in such a case are the async-signal-safe ones.

I think a lot of frameworks on OS X implicitly create threads behind the
scenes, and that might be the reason Apple documented such a restriction
without going into too much details.

BR,
Andrey.