Re: Multithread communication
Re: Multithread communication
- Subject: Re: Multithread communication
- From: Matt Neuburg <email@hidden>
- Date: Wed, 03 Feb 2010 11:45:38 -0800
- Thread-topic: Multithread communication
On Wed, 3 Feb 2010 11:30:15 -0500, "McLaughlin, Michael P."
<email@hidden> said:
>In a multithreaded app using NSOperationQueue and targeting Leopard, I am
>having an inordinate amount of trouble communicating the results of the
>thread computations to the main thread which acts as an overall coordinator.
>
>thread upon completion. The last thing each thread does is
>postNotificationName to the main thread saying that it is ready to return
>lots of data which it does via an NSPointerArray
>[ptr pointerArrayWithStrongObjects]
>and dictionary. The object which collects the results has a function
>getOpResults() which accesses the passed pointer.
Three things come immediately to mind just reading what you've said (without
seeing the actual code):
(1) Posting a notification does not, of itself, post "to the main thread".
Of course you may already know this. But it might be worth keeping in mind
that if you are code running in a background thread and you are not
explicitly saying performSelectorOnMainThread:, stuff that you trigger, even
thru a notification, is still triggered in the background thread.
(2) NSOperationQueues and NSOperations are KVO compliant, so it should be
sufficient to observe - there shouldn't be any need for an explicit posting
of a notification in any case. Usually you just observe "isFinished". Of
course you will receive *that* notification in the background thread, so you
must *still* then jump out to the main thread explicitly with
performSelectorOnMainThread:.
(3) NSOperationQueues and NSOperations are objects, which means that they
have their own data and persist if you want them to. So once you *are* back
in the main thread you can return to these objects and pick up the data, at
your leisure, as it were; the thread is finished, the datat is just sitting
there, and you are the main thread so you are not danger of conflicting with
yourself (there can't be two main threads), and there is no need to pass
anything back via the notification or any other way. This approach may add a
measure of safety and clarity to your code.
I also like to arrange my code into regions with comments that state very
clearly whether a method is to run in a background thread or the main
thread.
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
AppleScript: the Definitive Guide - Second Edition!
http://www.tidbits.com/matt/default.html#applescriptthings
_______________________________________________
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