Re: Asynchronous Notification Does NOT Work
Re: Asynchronous Notification Does NOT Work
- Subject: Re: Asynchronous Notification Does NOT Work
- From: Bing Li <email@hidden>
- Date: Mon, 06 Jun 2011 12:36:22 +0800
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@hidden> 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@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