Re: thread protocol modifiers
Re: thread protocol modifiers
- Subject: Re: thread protocol modifiers
- From: James Bucanek <email@hidden>
- Date: Sun, 6 Jan 2008 00:04:41 -0700
William Zumwalt <mailto:email@hidden> 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
_______________________________________________
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