On 13 Sep 2011, at 22:53, Scott Ribe wrote: > On Sep 13, 2011, at 3:07 PM, jonat...@mugginsoft.com wrote: > >> Are you sure about this? > > Yes. From man fork: > > There are limits to what you can do in the child process. To be totally > safe you should restrict yourself to only executing async-signal safe > operations until such time as one of the exec functions is called. All > APIs, including global data symbols, in any framework or library should > be assumed to be unsafe after a fork() unless explicitly documented to be > safe or async-signal safe. If you need to use these frameworks in the > child process, you must exec. In this situation it is reasonable to exec > yourself. >
tn2083 has some further OS X specific detail (see daemonization). http://developer.apple.com/library/mac/#technotes/tn2083/_index.html Daemonizing Frameworks Many Mac OS X frameworks do not work reliably if you call fork but do not call exec. The only exception is the System framework and, even there, the POSIX standard places severe constraints on what you can do between a fork and an exec. Under the covers the daemon routine calls fork. Thus, if you call daemon and use frameworks above the System frameworks, you may run into problems. Critically, frameworks that are otherwise daemon safe, like Core Foundation, are not safe to call from this state. Important: In fact, in Mac OS X 10.5 and later, Core Foundation will detect this situation and print the warning message shown in Listing 13. Listing 13 Core Foundation complaining about fork-without-exec The process has forked and you cannot use this CoreFoundation \ functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_\ COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__() to debug. There are two common solutions to this problem: • adopt launchd — A launchd daemon does not call daemon, and thus does not suffer from this problem. This is the preferred solution. • exec yourself — If you can't adopt launchd (perhaps your product needs to support Mac OS X 10.3.x), you can solve this problem by exec'ing yourself. > Isn't that pretty much what I was saying before? Probably! What I take away from this is: 1. After a fork a child can do work without calling exec, but with severe constraints. 2. A forked process can escape the above constraints by execing itself. Regards Jonathan Mitchell Mugginsoft LLP ================================================ KosmicTask - the Integrated Scripting Environment for OS X. http://www.mugginsoft.com/KosmicTask ================================================ _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
