Re: Setting up an auxiliary task for use with Distributed Objects
Re: Setting up an auxiliary task for use with Distributed Objects
- Subject: Re: Setting up an auxiliary task for use with Distributed Objects
- From: Oleg Krupnov <email@hidden>
- Date: Fri, 17 Apr 2009 07:12:36 +0300
@Jeremy
> You can communicate with the task, since you seem to control it, by
> setting up a pipe (NSPipe) and setting its write/read file handles as
> the stdin/stdout for the task. The task can then send you a "ready to
> go" signal. You can use -[NSFileHandle
> waitForDataInBackgroundAndNotify] to get a callback when the "ready"
> signal is sent back. On the other side, you can have it check for a
> broken connection (is that possible with NSConnection/NSMachPort?) or
> just wait for a kill message to come across on its stdin, which your
> primary task can send over.
Yes, it's an option to consider, thanks. However, DO seems to provide
such a nice way to avoid using pipes, that I would first try to avoid
introducing them just for the purpose of handshaking and termination
the aux task.
@Ken
> with something like:
>
> while ([vendedObj shouldKeepRunning])
> [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode
> beforeDate:[NSDate distantFuture]];
>
I think I've seen this code somewhere in the docs, but I haven't and I
still don't understand how it can terminate the run loop, if the
beforeDate specifies distant future? The shouldKeepRunning flag seems
to be checked once at the beginning and never again. Could you explain
how it's supposed to work?
> Have you considered reversing the roles of the two processes, in terms of
> which is the "server" and which the "client"?
>
> You can have the main task register a connection under a known name. It
> will vend an object with which the auxiliary task will register. It will
> start the auxiliary task. The auxiliary task will obtain the vended object
> from the main task using the known name. The auxiliary task will create a
> worker object. It will pass that worker object to the main task in a
> check-in message. It will then run the run loop in the manner illustrated
> above. The main task will passively receive a reference (proxy) for the
> auxiliary task's worker object. It can then invoke methods of that object
> just as it would in the design you were working with.
>
It's a smart idea, but I don't see how it could help to block the main
process until the aux process is initialized. As I understood, the
advantage of this approach is that there's a way to notify the main
process asynchronously from the aux process that the latter is ready
to work. (So, the main process should temporarily switch into a
"waiting mode" until the notification arrives, right?) However, I'm
not sure that passing the worker object to the main task will work as
you designed. I'm afraid that instead of the proxy, the main task will
receive a copy of the worker object, because the worker object is not
vended. Isn't it what vending is for - to obtain proxies instead of
copies? An explanation would be appreciated.
_______________________________________________
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