On Jun 5, 2011, at 2:45 PM, Bing Li wrote: > In this case, notification might occur among two threads and both of them > are not the main thread.
This can't work. Notifications do not cross threads. They are delivered on the same thread in which they're posted or queued. What are you trying to achieve, from a high-level point of view. Don't describe the mechanism you think you want to use (e.g. asynchronous notification). Describe the high-level problem you're trying to solve, the goal you're trying to achieve. One starting point might be: why do you feel it's important for your notifications to be asynchronous? What problem would arise if your notifications were delivered synchronously? Frankly, there are relatively few cases where asynchronous notifications are the correct solution to a problem. Developers sometimes think they're appropriate when they aren't, because of preconceptions which aren't appropriate for Cocoa. The same can be said about threading, too. In most cases, Cocoa's asynchronous APIs, such as those for file and network I/O, can achieve the appropriate results, all on the main thread. The asynchrony would be provided by the framework, not by you explicitly introducing it. As for run loops, they really aren't that complicated. You won't get a tutorial on using them _in isolation_ because that makes no sense. Run loops are a generalization of any kind of wait-on-a-set-of-inputs API you may be familiar with (e.g. WaitForMultipleObjects). A run loop source encapsulates both "the thing to wait on" and the callback function or method to be invoked when that thing has arrived. Same with a timer; it encapsulates both when to fire and the callback function or method to call when it fires. This frees the code which runs the run loop from having to know either what inputs to wait on (because those inputs have already been added to the run loop) or how to handle those inputs. That allows for both the frameworks and your application code to add inputs to a run loop and know that, when the run loop is run, their inputs will be processed. The framework can run the run loop without having to be specially coded with explicit knowledge of what inputs your application might have added. Obviously, this is necessary to make the frameworks generalized for all sorts of applications. Similarly, your application can run the run loop without having to be specially coded with knowledge of what inputs the frameworks may have added. This allows for the frameworks' implementation details to remain hidden within the frameworks; those implementation details can even change with new releases without your application needing to be changed. The one hitch is that, of course, if nobody runs the run loop, then none of its inputs are processed or handled. In the main thread, the framework will run the run loop for you, if you let it -- if you allow flow of control to return to the framework after it has called your code. In other threads, you have to arrange to run the run loop yourself. That basically just means invoking one of the -run... methods on [NSRunLoop currentRunLoop], possibly repeatedly until some condition specific to your application has been met. Regards, Ken _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
