Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
And fork() does not work unless you exec() immediately after, in violation of all unix tradition.
I suppose iOS is still farther from unix.
An Interview with Brian Kernighan (InformIT)
Posted Oct 2, 2012 19:33 UTC (Tue) by mjg59 (subscriber, #23239)
Posted Oct 2, 2012 19:57 UTC (Tue) by dskoll (subscriber, #1630)
Are you sure? This OS X man page looks like the description of the normal UNIX fork.
Posted Oct 2, 2012 19:58 UTC (Tue) by dskoll (subscriber, #1630)
Oh, never mind... I missed the CAVEATS section. That's truly broken.
Posted Oct 2, 2012 20:46 UTC (Tue) by tialaramex (subscriber, #21167)
In terms of actual real world experience rather than linking to poorly labelled online documentation I can report that we never discovered any fork() related problems in our code when the CTO insisted on running it on his OS X laptop for several years. It ran slowly, and it missed various minor features (because OS X lacked the relevant system call or whatever and we had no reason to waste time fixing it just for one guy's laptop even if that guy was the one running the show) but it wasn't any less reliable and there was no sign of fork() being "in violation of all unix tradition"
There are other systems with a fork-like call that doesn't do what fork() actually does, including OS9 and, if we are to judge from that link, iOS but they don't claim to be Unix, let alone UNIX® do they?
Posted Oct 2, 2012 21:00 UTC (Tue) by ballombe (subscriber, #9523)
Posted Oct 2, 2012 21:18 UTC (Tue) by tialaramex (subscriber, #21167)
Posted Oct 2, 2012 21:53 UTC (Tue) by ballombe (subscriber, #9523)
Posted Oct 3, 2012 0:41 UTC (Wed) by quotemstr (subscriber, #45331)
That's a common pattern in GUI systems. On Windows, the NT kernel forks just fine --- it's the Win32 subsystem that can't handle it. Under Cygwin, fork works just fine, but the child doesn't inherit any of the Win32 GUI stuff. I honestly don't think of GUI^fork as a major limitation --- why on earth would you want to use the GUI in the child without execing first? How could you coordinate the parent GUI and child GUI?
Posted Oct 3, 2012 12:16 UTC (Wed) by ballombe (subscriber, #9523)
But my point is while there are various UNIX emulation layer available for windows, even one form MS which is POSIX certified, this does not make Windows a UNIX platform. The situation is increasingly similar on OS X.
Posted Oct 3, 2012 17:47 UTC (Wed) by quotemstr (subscriber, #45331)
> this does not make Windows a UNIX platform. The situation is increasingly similar on OS X.
Nobody cares about an OS being a "UNIX platform". People care about an OS being able to run useful software. Forking in a GUI program and doing GUI things in the child *just ain't useful*.
Posted Oct 3, 2012 20:37 UTC (Wed) by dskoll (subscriber, #1630)
What part of "snapshot" is unclear?
Posted Oct 4, 2012 15:28 UTC (Thu) by bronson (subscriber, #4806)
Posted Oct 4, 2012 19:23 UTC (Thu) by quotemstr (subscriber, #45331)
Posted Oct 4, 2012 0:41 UTC (Thu) by mpr22 (subscriber, #60784)
Posted Oct 4, 2012 15:32 UTC (Thu) by bronson (subscriber, #4806)
Posted Oct 2, 2012 21:42 UTC (Tue) by mjg59 (subscriber, #23239)
Posted Oct 2, 2012 21:01 UTC (Tue) by tialaramex (subscriber, #21167)
It seems that from 10.5 this caveat was added to the official OS X documentation. In that light I think it's safest to conclude that Apple realised fork() is hard (check out the long list of things a current Linux fork does to retain sanity in the face of threads, asynchronous I/O, capabilities and other fun toys that didn't exist at the dawn of Unix) and decided they don't care. It will probably work, but if it doesn't they aren't interested in explaining why/ fixing the problem.
On balance I agree this makes OS X a pretty shoddy Unix, but then, I would have been easily persuaded of that anyway.
Posted Oct 2, 2012 22:51 UTC (Tue) by the.wrong.christian (guest, #73127)
I'd wager most libraries are not fork safe, including such libraries as SQLite as mentioned in the SQLite FAQ. Libraries that talk to the outside world contain much state that is not safe to share.
I don't this makes Darwin especially shoddy (this is a Darwin "issue", BTW, rather than an OS X issue.)
Posted Oct 4, 2012 21:06 UTC (Thu) by ballombe (subscriber, #9523)
Fortunately, you are wrong. The X11 protocol allows the child to open its own display and create its own graphic context without interfering with the parent process.
Posted Oct 5, 2012 4:20 UTC (Fri) by Kit (guest, #55925)
Posted Oct 4, 2012 21:46 UTC (Thu) by wahern (subscriber, #37304)
The root of the problem is threading, and that exact same problem exists everywhere else. Historically, the behavior when both forking and threading was never well defined. The old rule was, never fork after starting a thread. And this rule still persists, even on systems like Solaris and Linux which actually try hard to make simultaneous forking and threading safe.
Now, if a third-party library starts up threads in the background, then it follows that the application should never fork after entering that library. If the application is linking that library at load-time, at the library initializes itself by starting threads, then technically the application should never, ever call fork.
Presumably, then, it would seem that some of Apple's libraries immediately spin up threads in the background (and/or initialize similar resources which don't behave well with fork). This is nothing new.
Posted Oct 11, 2012 10:10 UTC (Thu) by nix (subscriber, #2304)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds