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: Ken Thomases <email@hidden>
- Date: Fri, 17 Apr 2009 02:10:42 -0500
On Apr 16, 2009, at 11:12 PM, Oleg Krupnov wrote:
@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?
The -[NSRunLoop runMode:beforeDate:] method returns after processing a
single firing of an input source. So, it _can_ block until the date
provided if nothing is happening, but if a message comes in via D.O.
it will be processed and then control will return to the while loop.
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?)
I don't know if your main task is a GUI application or not. If it is,
then you wouldn't block, you'd just let the main event loop (i.e. run
loop) run. When the check-in message arrives (asynchronously), you'd
do whatever you want at that time in the implementation of the check-
in method.
If your main task isn't already running a run loop, you can run it
manually in a "waiting mode" if you like.
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.
No, vending an object and passing objects by reference/proxy are two
independent concepts. It's true that the vended object is always
passed by reference and thereby the client receives a proxy. But
other objects may also be passed by reference, and the receiver gets a
proxy. In fact, pass-by-reference is the default in most cases in D.O.
See this article of the Objective-C 2.0 guide, in particular the part
about "Proxies and Copies":
http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/ocRemoteMessaging.html
So, if the aux task passes its worker object to the main task's check-
in method, then the main task will actually get a proxy for that
worker object. When the main task then invokes methods on the proxy,
the work will be carried out in the aux task. (If you want the main
task to be able to continue to do other things while the aux task
works, those methods on the worker object should probably be "oneway
void".)
Regards,
Ken
_______________________________________________
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