Dear Ken and Jens, I appreciate so much for your detailed explanations!
In my system, a server needs to handle requests from remote clients. Multiple local threads are raised to listen to the specific port concurrently. When a request is received by one of the thread, it must notify other responding threads asynchronously. The reason to notify asynchronously is to avoid possible blocking by the responding threads. But I think it is not necessary to use asynchronous notification if the responding threads are non-blocking. This is the high-level framework in my system. Best regards, Bing On Mon, Jun 6, 2011 at 4:50 AM, Ken Thomases <[email protected]> wrote: > 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]
