User: Password:
|
|
Subscribe / Log in / New account

fork

fork

Posted Oct 2, 2012 21:01 UTC (Tue) by tialaramex (subscriber, #21167)
In reply to: fork by tialaramex
Parent article: An Interview with Brian Kernighan (InformIT)

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.


(Log in to post comments)

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds