Re: thread protocol modifiers

FROM : William Zumwalt
DATE : Sat Jan 05 22:35:53 2008

> You're talking about threads, but the issue is really
> Distributed Objects. While DO can send messages between threads,
> it's principle strength is its ability to communicate between
> processes and systems. Unless you *need* to communicate between
> processes, you have numerous -- and far more efficient --
> alternatives beyond DO to choose from. In your case, queuing
> messages or using some other kind of inter-thread FIFO would
> probably serve your needs.
>


But I think that's the reason I chose to use DO, because I am communicating
between processes by having my client send several hundred or more objects
of data, and then send commands for the server to operate on that data.


>
> Distributed Objects works through the run loop. When you send a
> message to a distant object, the object and the method
> invocation is encoded and piped to a port on the run loop that
> created the object. The run loop dispatches the message and send
> the results back to the run loop of the process/thread that sent
> the message.
>
> As you've discovered, unless you use the (oneway void) modifier,
> the sender blocks until the reply message is placed on its run loop.
>


So I feel that I'm still using the right method to communicate with, but you
have raised something important that I hadn't seen before. I'm showing my
servers run loop below, but what I'm wondering about is that the class that
subclasses this main server class where I implement my commands ... it has
it's own main loop (which I try to show in the 'run' method below).

Here is how I create my server process (serverObject), and once my server is
up and running, it is then able to receive a command such as 'run', 'pause',
etc...

+ (void) _connectWithPorts:(NSArray *) portArray
{
    NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];

    NSConnection *controllerConnection = [NSConnection
        connectionWithReceivePort:[portArray objectAtIndex:0]
        sendPort:[portArray objectAtIndex:1]];

    int serverTag = [[portArray objectAtIndex:2] intValue];

    /*
    * Now we create the server instance that will actually do the data
    * processing. Actual data processing behavior will be in the subclass.
    */
    NetworkServer *serverObject = [[self alloc]
        initForParent:(id) [controllerConnection rootProxy]
withTag:serverTag];
    [serverObject setConnection:controllerConnection];

    [controllerConnection setRootObject:serverObject];

    @try {
        [[controllerConnection rootProxy] setServer:serverObject
            tag:serverTag];
    }
    @catch (NSException *exception) {
        NSLog(@"NetworkServer:_connectWithPorts caught %@: %@",
            [exception name], [exception  reason]);
    }

    [[controllerConnection rootProxy]
        performSelectorOnMainThread:@selector(handleServerSetupComplete)
        withObject:nil waitUntilDone:NO];

    do {
        [[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode
            beforeDate:[NSDate distantFuture]];
    } while ([serverObject isRunning]);

    [[controllerConnection receivePort] invalidate];
    [[controllerConnection sendPort] invalidate];
    [controllerConnection release];

    [serverObject release];
    [pool release];
}

Two example commands that this server is able to receive.

- (void) run
{
    [self _run];

    return;
}

- (void) pause
{
    [self _pause];

    return;
}

The data processing implementation methods are in a subclass of the server
class above and has it's own main loop to process data. Could this be the
problem because you said DO works through the run loop, and I don't think
I'm giving it a chance to return back into the run loop because the server
process is hung up inside this loop processing data.

- (void)_run
{
    ...

    while (processingData) {
      ...
    }
}