Re: NSRunLoop processing order of NSPort delegates
Re: NSRunLoop processing order of NSPort delegates
- Subject: Re: NSRunLoop processing order of NSPort delegates
- From: Chris Kane <email@hidden>
- Date: Sun, 27 May 2001 16:40:16 -0700
On Monday, May 21, 2001, at 09:02 AM, Leigh Smith wrote:
>
Unfortunately I didn't get an answer on macosx-dev@omnigroup to this,
>
so hopefully asking here will get closer to those who can examine the
>
source code.
You have to make some allowances for WWDC-in-preparation-and-progress.
>
According to the NSRunLoop documentation for
>
acceptInputForMode:beforeDate:
>
>
"Blocks awaiting input from the ports in the port list for the input
>
mode mode until the time specified by limitDate. Use the
>
limitDateForMode: method to calculate limitDate. If input arrives, it
>
is processed using the NSPort delegates. This method does not check the
>
timers associated with mode, thus it does not fire timers even if their
>
scheduled fire dates have passed."
>
>
However I'm finding that on receipt of a message (via an NSConnection)
>
on a monitored port, NSRunLoop will exit acceptInputForMode:beforeDate:
>
or runMode:beforeDate: *before* the delegate method is called, i.e two
>
iterations of acceptInputForMode: is needed to actually call the method.
Well, before the delegate method is called on YOUR port. Somebody
else's input source might be getting fired, causing the method to return.
limitDateForMode: and acceptInputForMode:beforeDate: should always be
used in a loop, and you should never "expect" your source(s) to be
handled with any particular number of iterations or whatever. If I try
to recall everything I know about using these directly and potential
pitfalls, this is the most general way in which these should be used:
while (some optional condition, or true) {
d = limitDateForMode:
if (some optional condition, or false) break;
acceptInputForMode:beforeDate:d
}
acceptInputForMode:beforeDate:[NSDate distantPast]
If you want to run the run loop until your port delegate has been
notified, then you would define a condition for the while loop (like:
!done) based on state that the delegate method can set (done = YES), and
omit the if statement.
The final poll is needed in obscure cases involving delayed performs
that might have been scheduled during the callouts from the run loop in
the loop (timers and ports "firing") and you may get along happily
without it. If the run loop gets back to being run in a normal way
(say, by the AppKit or whatever), any such will be fired at that point.
Chris Kane
Cocoa Frameworks, Apple, Inc.