Re: thread protocol modifiers
Re: thread protocol modifiers
- Subject: Re: thread protocol modifiers
- From: James Bucanek <email@hidden>
- Date: Sat, 5 Jan 2008 18:35:38 -0700
William Zumwalt <mailto:email@hidden> wrote (Saturday,
January 5, 2008 2:35 PM -0600):
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.
The $64,0000 question is this: Is your server a separate process
or just a thread in your application's process.
If your server is really running as it's own process, then DO is
the way to go. If your server is just a new thread started
within your application, then DO is probably more trouble than
it's worth (for this particular situation).
Note that the programming snippets that you included don't
answer the question because it doesn't show how the
_connectWithPorts: method gets started. Is this initialization
code in a separate executable? Then it's probably running as a
separate process. However, if you start _connectWithPorts: with
+[NSThread detachNewThreadSelector:...] then it's just another
tread within your application's process. It's a very important
distinction to make.
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) {
...
}
}
That's exactly how DO works. If you need to get back to your run
loop to dispatch the next message in the queue, then you need to
return from _run sooner. For example, forking a new thread to do
the work then returning from _run immediately. But this just
pushes your worker threads one level deeper in the architecture;
it's really not solving any of your fundamental problems.
--
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