Re: thread protocol modifiers

FROM : James Bucanek
DATE : Sun Jan 06 08:04:41 2008

William Zumwalt <mailto:<email_removed>> wrote (Saturday,
January 5, 2008 7:35 PM -0600):
>Maybe this will help explain my intentions ... once the thread is started
>doesn't mean I'm processing data yet, this just sets up the server process
>and passes all my potentially thousands of encoded objects to the server
>which is not it's own app process, rather, just another thread from within
>the application process. Then the user can click on media like buttons to
>run, pause, save, and stop on the data processing and terminate the thread
>after saving the results.


That at least settles the same-process question.

>It's a scientific application and it's likely the user will repeat this
>process many times testing new configurations so I expect the many different
>server object types, all w/ different algorithms that are subclassed, to get
>run in a single session. But the server object itself isn't expected to stay
>up for the life of the application, it's just a data processing thread that
>may last for a few minutes + depending on the amount of data, only to be
>followed by another user configuration of data and another data processing
>test.
>
>What initially influenced my decision was that I had a lot of data patterns
>that needed to be communicated to the server thread and rather than pass
>pointers to the data, I passed the objects themselves so that the server
>process would have it's own copy of the data to operate on and not have to
>worry about the user changing it while it's being operated on.


Sadly, I have bad news. You have two needs, neither of which is
going to be solved using distributed objects. (Well, technically
one could but it's not a good use of DO.)

What you need is:

(a) A worker thread that has an object to do the work.
(b) A message system by which you send jobs to the worker thread
to be performed asynchronously. The jobs need to be performed in
the order they were queued.
(c) The worker works on a copy of the original object.

Distributed Objects is an IPC/RPC mechanism. It's purpose is to
allow you to communicate with a remote object (one that might
exist in another process or even another machine) as though it
was a local object. While it uses run loop queues to perform its
communications, it's not designed to manage queues of
asynchronous jobs/messages. In fact, DO primary purpose is to
provide a synchronous method calling. And while it will make
copies of objects, it normally does not. The object that the
server uses is (conceptually) the same object that the client
sent it. Any changes made to the object by the server will
affect the original object.

So what you're trying to do is turn the side-effects of
distributed objects into a worker thread management system. You
might make it work, but you're fighting an uphill battle.

My suggestion would be to take a step back and look at something
like YAMessageQueue. The changes in your code should be minimal.
Instead of creating a server and starting a thread which starts
a run loop, your code would

(a) Start a thread, passing it a copy of the object that will do
the work
(b) Send it messages to perform using YAMessageQueue (or some
similar mechanism).
(c) When the message finishes executing, it can communicate the
results back to the main thread via another queue or simply with
[NSObject peformSelectorOnMainThread:...]
(d) Implement the NSCopying protocol on the objects you need to
copy. (Sending an object to a server using DO doesn't make a
copy of it; it only creates a proxy objects that eventually
invokes changes on the original.)

This solution will be vastly more efficient, and probably easier
to write and maintain. More importantly, you'll have real
control over message execution order and scheduling.

--
James Bucanek