Re: Creating NSAttributedString objects using WebKit in secondary thread
Re: Creating NSAttributedString objects using WebKit in secondary thread
- Subject: Re: Creating NSAttributedString objects using WebKit in secondary thread
- From: Michael Ash <email@hidden>
- Date: Tue, 12 May 2009 09:49:29 -0400
2009/5/12 Dragan Milić <email@hidden>:
> On uto 12. 05. 2009., at 06:54, Michael Ash wrote:
>
>> I think you've misunderstood. There is no problem with the fork/exec
>> approach here.
>
> You actually are spot on with that remark, my knowledge of UNIX system calls
> is not very broad, on the contrary it's rather limited I'd say.
>
> Thank you all for the suggestions, I'll definitely investigate
> (read-try-learn) fork()/exec() route and any eventual question would be
> off-topic for this list anyway.
In case it helps to have a really quick summary, here's the short
version on what the heck all of this stuff is doing.
UNIX is very strange in that it splits out the concept of "create a
new process" and "load a program into this process". The fork call
creates a new process which is an exact duplicate of the current one
(except that it has a new process ID and all the other threads besides
the one that called fork don't exist in the new one). Conceptually,
fork() is called once and returns twice, once in the parent and once
in the child.
The exec() family of calls (there's a whole mess of them, look up 'man
execl' to get started there) simply loads the new program into the
existing process, replacing the program that's already there.
As such, to spawn a subprocess, you generally call both fork and exec,
fork first to create a new process, then exec to load a new program
into it.
However, if you're going to go the subprocess route, you're probably
better off looking into NSTask, which encapsulates all this craziness
into a nice Objective-C wrapper. The main reason to use the UNIX calls
directly would be if, for example, you were going to call fork alone
and not exec. As I mentioned before, this approach is fraught with
danger and difficulty, so there's not much point to it.
Mike
_______________________________________________
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