Re: threaded/forking server and distributed objects
Re: threaded/forking server and distributed objects
- Subject: Re: threaded/forking server and distributed objects
- From: email@hidden
- Date: Thu, 13 Jul 2006 15:35:00 +1000
Sorry to rain on your parade, but forking in a Cocoa app is a big no-
no. Chris Kane explained January last year:
SUBJECT: continuing after fork() (Re: Problems with NSTimer and
NSRunLoop/CFRunLoop)
FROM : Chris Kane
DATE : Wed Jan 12 05:10:46 2005
You cannot continue executing the child process of a fork() for
executables which link with any Apple libraries(*) (directly or
indirectly) and want to use that functionality on the child side of
the
fork(), without a paired execve() in the child. That is, if you want
to fork() and have the child continue to run and use Apple libraries,
the child must execve() and "continue" from main().
The problem is that fork() does not actually replicate all kernel
resources (and perhaps other bits I don't know about) from the parent
process into the child, but it does replicate memory. Thus there can
be code which thinks everything is happy because the memory holding
handles to kernel resources looks like it is initialized and whatnot,
but the kernel resources are missing underneath.
Sprinkling checks all over to see if the resource handle is good "in
case a fork() has happened since the last check" would be laborious
and
in some cases expensive in some hot code paths, when continuing after
fork() is actually not very common. So the checks are left out.
I thought there was a Tech Note on this, and perhaps there was at one
point, but I can't find it now, or the information has moved
elsewhere.
Basically, after fork() you need to execve() (or other exec variant),
so that library initializers and whatnot are executed in the
context of
the child to do any 1-time set-up or whatever else the libraries
normally do when an app is launched. The usual pattern is to pass an
extra argument or environment variable to the child to let it know to
not fork() again, that it is the child.
(*) this is not necessarily just true of Apple libraries, but can be
true of BSD/open source libraries as well. But "any Apple library" is
a good starting point. CoreFoundation and Foundation are two such
Apple libraries that I personally know about, and the Mach ports used
by the run loop system is one example of kernel resources which are
not
replicated.
Chris Kane
Cocoa Frameworks, Apple
Wade Tregaskis
ICQ: 40056898
AIM, Yahoo & Skype: wadetregaskis
MSN: email@hidden
iChat & email: email@hidden
Jabber: email@hidden
Google Talk: email@hidden
http://homepage.mac.com/wadetregaskis/
-- Sed quis custodiet ipsos custodes?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden