• 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: Any caveats to using fork in a Foundation/CoreFoundation tool?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Any caveats to using fork in a Foundation/CoreFoundation tool?


  • Subject: Re: Any caveats to using fork in a Foundation/CoreFoundation tool?
  • From: glenn andreas <email@hidden>
  • Date: Thu, 25 Oct 2007 12:15:30 -0500


On Oct 25, 2007, at 11:45 AM, Jim Correia wrote:

I have the need to launch a tool from my GUI application that needs to be in its own process group (i.e. the parent process should not be the GUI app which launched it, since it needs to outlive the parent process.)

It will use CFMessagePort to communicate with the parent app.

I seem to recall that using fork not followed immediately by exec was a bad idea for Foundation/CoreFoundation tools or applications, but at the moment I can't find those references in the archives.

Is using fork (or daemon, as the case may be) at the top of main going to cause me grief when I want to later use Foundation or CoreFoundation services?

Yes, it will cause problems - basically, after a fork, you not suppose use anything above libSystem - according to POSIX, you're not even suppose to use anything except those that are listed as async signal handler safe (according to one web page "In the child, do not call any library functions after calling fork() and before calling exec(). One of the library functions might use a lock that was held in the parent at the time of the fork(). The child process may execute only Async-Signal-Safe operations until one of the exec() handlers is called"). So even malloc could be bad...


So basically all of CoreFoundation is bad (check out the source for CFMachPort.c in the current CF source to see where it tries to gracefully handle this problem - with graceful meaning "print a meaningful message and exit" rather than "hang").


Any other recommended approaches?

I'd add a "magic flag" to the argv list - your tool will check that, and if missing, will fork and exec itself with that flag added (and then quit). If it is present, then you are good to go...



Glenn Andreas email@hidden
<http://www.gandreas.com/> wicked fun!
quadrium2 | build, mutate, evolve, animate | images, textures, fractals, art



_______________________________________________

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: 
 >Any caveats to using fork in a Foundation/CoreFoundation tool? (From: Jim Correia <email@hidden>)

  • Prev by Date: Re: Any caveats to using fork in a Foundation/CoreFoundation tool?
  • Next by Date: problem with NSString, UTF8, pathnames
  • Previous by thread: Re: Any caveats to using fork in a Foundation/CoreFoundation tool?
  • Next by thread: problem with NSString, UTF8, pathnames
  • Index(es):
    • Date
    • Thread