Re: Techniques for thread communication
Re: Techniques for thread communication
- Subject: Re: Techniques for thread communication
- From: Tom Harrington <email@hidden>
- Date: Sun, 7 Sep 2003 22:02:11 -0600
On Sunday, September 7, 2003, at 03:21 PM, Eric Scharff wrote:
I have a thread that continuously does computationally expensive
things in the background, but which occasionally needs to present
information to the user. Since the AppKit is mostly not-reentrant, I
want to make sure I do this the "right way."
It seems I have several options:
1. Use the NSNotificationCenter. The thread posts messages when data
is available, and the main app gets these events and updates.
2. Use NSConnection to establish a communication channel between the
"main app" and the thread, and send messages through the distributed
object proxies.
3. Use an NSTimer in the main app to periodically poll the thread.
4. Use NSInvocation somehow for the thread to push messages to the
main app.
I'm leaning heavily toward (1) because the code is the simplest and
cleanest. Option (2) is somewhat appealing because eventually I could
replace the local server with a cluster of distributed servers.
You cannot do #1, because it doesn't work this way. The docs for
NSNotification explain that:
"In a multithreaded application, notifications are always delivered in
the thread in which the notification was posted, which may not be the
same thread in which an observer registered itself."
So, if you post from the worker thread, you notify in the worker
thread, even if the registration happened in the main thread. The main
thread never knows that anything happened until it stumbles across
updated data.
Using #2 is effective and recommended in Apple's multithreading
documentation. Read up; they even give you sample code that'll make it
more or less straightforward.
Using #3 may have similar problems to #1. In this case you get the
main thread initiating the communication, but the worker is not
synchronized in any way. So the data you're getting may not be ready
for reading when the main thread decides to check on it.
I'm not sure how #4 might work; you may be thinking more of something
like NSObject's -performSelectorOnMainThread:withObject:waitUntilDone:.
--
Tom Harrington
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.