Ken, you really made the whole issue clear to me.
I ran my app in the debugger with breakpoints inside the methods of
the objects in the array, and as you say, every single method is
executed in the main thread!
I'll have a look at YAMessageQueue.
Thanks again for your great input,
Peter
Am 01.02.2011 um 05:45 schrieb Ken Thomases:
On Jan 31, 2011, at 8:48 PM, Peter Lübke wrote:
Thanks Ken,
You're welcome.
Am 01.02.2011 um 02:07 schrieb Ken Thomases:
So, you have effectively failed to shift the work from the main
thread to the worker thread. The main thread is a "server" doing
all of the work on the behalf of its client, the worker thread.
Not quite... In this case, the worker thread is the server.
If the main thread owns the real array and the worker thread
receives a proxy of the array (and thus its elements), then the
main thread is the server, serving the services of the array and
its elements to the worker thread. It doesn't matter how you
intended/designed things to work.
I guess that's why the main thread is all the way responsive.
This probably has to do with the granularity of the messages that
the worker thread is sending to the array and its elements. If
it's invoking many quick methods, then the main thread will remain
responsive, even if it's doing all the work. That's because there
are frequent opportunities for it to respond to GUI events between
messages from the worker thread.
Also, you want to design a fairly coarse-grained protocol of
requests that a client can make of the server -- few requests to
do some big chunks of work, not many requests for small chunks of
work.
This is what I thought I was doing, the "bad" thing - if I get it
right - is that I pass the array to the server?
Basically, yes. It's not a hard and fast rule that doing so is
always wrong or bad. Just remember that every method invoked on
the proxy is delivered to the original object over the D.O.
connection, the provider of that original object does the work, and
then results are passed back -- and if the results are non-value
objects, they are passed by reference, meaning as proxies. So, the
proxiness can cascade.
There's a bunch of these arrays around, all containing objects of
one class. There's another bunch of objects of various classes
that access these objects.
I didn't like the idea of implementing the creation of threads
that always kind of do the same sort of work in each of these
different classes.
So I thought it might be a good idea to have a singleton "thread
manager" create worker threads as needed and coordinate those
different object's requests.
That's a thread pool. You can use any number of synchronization
techniques to give work to the threads in a pool. NSConditionLock
is nice and straightforward. See <http://developer.apple.com/
library/mac/documentation/Cocoa/Conceptual/Multithreading/
ThreadSafety/ThreadSafety.html>.
There are also message queue implementations to do something a bit
like D.O., except without the proxying. I've used YAMessageQueue
in the past. It's also not too hard to roll your own.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
