| |||||||||||||
An Interview with Brian Kernighan (InformIT)An Interview with Brian Kernighan (InformIT)Posted Oct 2, 2012 19:57 UTC (Tue) by dskoll (subscriber, #1630)In reply to: An Interview with Brian Kernighan (InformIT) by ballombe Parent article: An Interview with Brian Kernighan (InformIT)
And fork() does not work unless you exec() immediately after, in violation of all unix tradition. Are you sure? This OS X man page looks like the description of the normal UNIX fork.
(Log in to post comments)
An Interview with Brian Kernighan (InformIT) Posted Oct 2, 2012 19:58 UTC (Tue) by dskoll (subscriber, #1630) [Link] Oh, never mind... I missed the CAVEATS section. That's truly broken.
fork Posted Oct 2, 2012 20:46 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
That's actually a misleadingly titled iOS manual page as far as I can tell.
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?
fork Posted Oct 2, 2012 21:00 UTC (Tue) by ballombe (subscriber, #9523) [Link]
The Core foundation framework will actively abort if called after a fork().
This is well documented.
fork Posted Oct 2, 2012 21:18 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Needless to say our software (written primarily for Linux, but never deliberately made non-portable) did not use this "Core foundation framework" which judging from its name I'd guess is neither the "core" of the system, nor any sort of "foundation" and possibly not even a framework but instead some layer of crap on the top.
fork Posted Oct 2, 2012 21:53 UTC (Tue) by ballombe (subscriber, #9523) [Link]
"core foundation" is used by "cocoa" which is the standard GUI library. This is used by e.g. the libfltk "native" port on OS X.
So if you write a portable program that use libfltk as toolkit, then it get linked to "core foundation" on OS X. So basically GUI^fork.
fork Posted Oct 3, 2012 0:41 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
> So basically GUI^fork.
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?
fork Posted Oct 3, 2012 12:16 UTC (Wed) by ballombe (subscriber, #9523) [Link]
The parent has no GUI. It produces a set of data for the child. The fork causes the child to get a snapshot of the data. The child displays the data graphically. If the child were to exec() it would lose the data snapshot.
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.
fork Posted Oct 3, 2012 17:47 UTC (Wed) by quotemstr (subscriber, #45331) [Link]
> The fork causes the child to get a snapshot of the data. The child displays the data graphically.
Shared memory.
> 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*.
fork Posted Oct 3, 2012 20:37 UTC (Wed) by dskoll (subscriber, #1630) [Link] ...Shared memory. What part of "snapshot" is unclear?
fork Posted Oct 4, 2012 15:28 UTC (Thu) by bronson (subscriber, #4806) [Link]
Wouldn't MAP_PRIVATE work for that? (curious, I've never tried)
fork Posted Oct 4, 2012 19:23 UTC (Thu) by quotemstr (subscriber, #45331) [Link]
MAP_PRIVATE only works once. You can't use it to create multiple versioned snapshots.
fork Posted Oct 4, 2012 0:41 UTC (Thu) by mpr22 (subscriber, #60784) [Link] I'm presuming the amount of data involved would be unreasonable to pass over a pipe.
fork Posted Oct 4, 2012 15:32 UTC (Thu) by bronson (subscriber, #4806) [Link]
Or that it doesn't serialize well, like trees or video processing data.
fork Posted Oct 2, 2012 21:42 UTC (Tue) by mjg59 (subscriber, #23239) [Link]
The Core Foundation framework isn't part of POSIX, so has no bearing on how UNIX or otherwise an OS is.
fork Posted Oct 2, 2012 21:01 UTC (Tue) by tialaramex (subscriber, #21167) [Link]
Ah, OK, I found this
https://developer.apple.com/library/mac/#documentation/Da...
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.
fork Posted Oct 2, 2012 22:51 UTC (Tue) by the.wrong.christian (guest, #73127) [Link]
I'd safely assume that any X11 GUI app that fork'ed then executed GUI calls would suffer from undefined behaviour. Apart from anything else, it'd be sharing an X11 connection with it's parent process, so there would be all sorts of concurrency issues.
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.)
fork Posted Oct 4, 2012 21:06 UTC (Thu) by ballombe (subscriber, #9523) [Link]
> I'd safely assume that any X11 GUI app that fork'ed then executed GUI calls would suffer from undefined behaviour. Apart from anything else, it'd be sharing an X11 connection with it's parent process, so there would be all sorts of concurrency issues.
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.
fork Posted Oct 5, 2012 4:20 UTC (Fri) by Kit (guest, #55925) [Link]
How many applications out there actually take advantage of that ability? I'm fairly certain that sort of exotic thing isn't ever used by either GTK or Qt. X11 has a lot of flexibility that seems to never actually get used for one reason or another.
fork Posted Oct 4, 2012 21:46 UTC (Thu) by wahern (subscriber, #37304) [Link]
It only makes it as shoddy as any other Unix.
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.
fork Posted Oct 11, 2012 10:10 UTC (Thu) by nix (subscriber, #2304) [Link]
Well, this sort of thing is why pthread_atfork() was invented, so that libraries could hide their threaded implementation from their users. A properly written threaded library should not prevent its callers from forking.
|
|||||||||||||