Re: thread protocol modifiers

FROM : James Bucanek
DATE : Sat Jan 05 17:09:59 2008

William Zumwalt <mailto:<email_removed>> wrote (Friday,
January 4, 2008 6:06 PM -0600):

>I've been trying to chase down a problem with my thread for sometime
>and I think
>I've found the problem with why I can't click on my interface even though I
>have a thread processing my data in the background ... so I have a few
>questions about protocol modifiers which I'm looking at as the culprit.


William,

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.

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.

As for the out-of-order messages, I don't think there are any
delivery order guarantees in DO. It's impractical that there
would be any, since DO is designed to work over asynchronous
communication links.

My long-winded point is this: Your "server" is really a worker
thread. It performs work in a separate thread within the same
process and needs to deliver that work to your main thread when
done. Distributed Objects really isn't the best fit for this pattern.

As others have suggested, I suspect that something like
YAMessageQueue is a much better solution for your application.
It's thread friendly, doesn't have any object encoding/decoding
overhead, doesn't require any special declarations, and it won't
gum up your run loops.

--
James Bucanek