On Aug 5, 2010, at 10:27 AM, Jeff Johnson wrote:
> Why do you just set a short timeout rather than distantFuture? That's why I
> usually do.
Because polling is bad. More specifically, if you choose a short timeout, this
loop consumes CPU time and keeps bits of your code hot in the VM cache. Bu
On Aug 5, 2010, at 12:10 PM, Jens Alfke wrote:
> The wait code looks like:
>while (_busy) {
>if (![[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode
> beforeDate: [NSDate distantFuture]])
>break;
>}
Since you're waiting on an NSTask to finish, is there a reason
Le 5 août 2010 à 19:10, Jens Alfke a écrit :
> I’ve got a place in my code where I need to block waiting for an
> otherwise-asynchronous action to complete, so I use a fairly standard
> technique of running a nested runloop. But sometimes the runloop just keeps
> waiting forever even after the
Hi Jens.
Why do you just set a short timeout rather than distantFuture? That's why I
usually do.
-Jeff
On Aug 5, 2010, at 12:10 PM, Jens Alfke wrote:
> I’ve got a place in my code where I need to block waiting for an
> otherwise-asynchronous action to complete, so I use a fairly standard
>
On Thu, Aug 5, 2010 at 10:10 AM, Jens Alfke wrote:
> What I’m guessing is that running a delayed block does not count as an “input
> source”. That’s kind of frustrating, because it makes the runloop’s behavior
> highly dependent on internal details of framework classes — in this case, how
> was
