On Oct 8, 2014, at 1:45 PM, Jens Alfke <j...@mooseyard.com> 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 (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
