• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Task dispatching
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Task dispatching


  • Subject: Re: Task dispatching
  • From: "email@hidden" <email@hidden>
  • Date: Wed, 14 Sep 2011 09:50:11 +0100

On 13 Sep 2011, at 22:53, Scott Ribe wrote:

> On Sep 13, 2011, at 3:07 PM, email@hidden 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 (email@hidden)

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:

This email sent to email@hidden

References: 
 >Task dispatching (From: Jon Sigman <email@hidden>)
 >Re: Task dispatching (From: Scott Ribe <email@hidden>)
 >Re: Task dispatching (From: Jon Sigman <email@hidden>)
 >Re: Task dispatching (From: Jens Alfke <email@hidden>)
 >Re: Task dispatching (From: Scott Ribe <email@hidden>)
 >Re: Task dispatching (From: "Stephen J. Butler" <email@hidden>)
 >Re: Task dispatching (From: Scott Ribe <email@hidden>)
 >Re: Task dispatching (From: "email@hidden" <email@hidden>)
 >Re: Task dispatching (From: Scott Ribe <email@hidden>)

  • Prev by Date: Cocoaheads Lake Forest Meeting tomorrow, Wed. Sep. 14
  • Next by Date: Re: Responder-Chain question.
  • Previous by thread: Re: Task dispatching
  • Next by thread: Re: Task dispatching
  • Index(es):
    • Date
    • Thread