Re: Waiting for a future runloop-based callback
Re: Waiting for a future runloop-based callback
- Subject: Re: Waiting for a future runloop-based callback
- From: Ken Thomases <email@hidden>
- Date: Wed, 08 Oct 2014 13:57:13 -0500
On Oct 8, 2014, at 1:45 PM, Jens Alfke <email@hidden> wrote:
> In some circumstances the program … runs a nested runloop like this:
> while (!taskIsComplete)
> [[NSRunLoop currentRunLoop] runMode: @"myCustomMode"
> beforeDate: [NSDate distantFuture]];
> where taskIsComplete is some flag that will get set by the target method invoked from the task thread.
> Over on the task thread, when it completes the task it calls:
> [originator performSelector: @selector(taskDone:) onThread: originatingThread withObject: self
> waitUntilDone: NO modes: @[@"myCustomMode"]];
> where the -taskDone: method will set that taskIsComplete ivar that the wait code is checking.
>
> Unfortunately this doesn't work, because the runloop immediately bails out and returns NO from -runMode:beforeDate:. Apparently this is because there are no input sources registered for myCustomMode. Which is true, but that doesn't mean that no events are going to arrive for that mode! The problem seems to be that this part of the runloop implementation doesn't understand about delayed-perform-in-mode calls.
It's not about "understanding" perform-selector calls. It's simply that there's no input source at the time you're running the run loop. The fact that there may be input sources in the future doesn't matter.
> What's the workaround? Should I add some sort of no-op input source to the runloop for my custom mode?
Yes. Just add an [NSPort port] to the run loop.
> That smells very hacky.
Yeah, but what are you gonna do?
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