> On Nov 20, 2014, at 03:59, Ken Thomases <k...@codeweavers.com> wrote: > > On Nov 19, 2014, at 1:00 PM, Maxthon Chan <m...@maxchan.info> wrote: > >> I am writing an Objective-C wrapper for CFRunLoopSource called >> KLSRunLoopSource, that matched a Version 0 run loop source to an object by >> using delegation for callbacks. Now I have problem mapping the schedule and >> cancel callbacks to Objective-C. >> >> Constructing the CFRunLoopSourceContext using Objective-C object is not that >> difficult as several toll-free bridged methods between NSObject and >> CFTypeRef can be leveraged like the following, but three callbacks have to >> be delegated: >> >> _runLoopSourceContext.version = 0; >> _runLoopSourceContext.info = (__bridge void *)self; >> _runLoopSourceContext.retain = CFRetain; // [self retain] >> _runLoopSourceContext.release = CFRelease; // [self release] >> _runLoopSourceContext.copyDescription = CFCopyDescription; // [self >> description] >> _runLoopSourceContext.equal = CFEqual; // [self equal:] >> _runLoopSourceContext.hash = CFHash; // [self hash] >> _runLoopSourceContext.schedule = _KLSRunLoopSourceDidSchedule; // >> [self didAddToRunLoop:inMode:] >> _runLoopSourceContext.cancel = _KLSRunLoopSourceDidCancel; // [self >> didRemoveFromRunLoop:inMode:] >> _runLoopSourceContext.perform = _KLSRunLoopSourcePerform; // [self >> didTrigger]; >> >> The last three call back functions, beginning with _KLS, are the ones that >> will eventually call the delegate methods. However for delegate methods, >> didAdd and didRemove call for an NSRunLoop object that should map to the >> corresponding CFRunLoop passed into my call back. Any suggestions on how to >> do it? > > There is no general way to get the NSRunLoop that corresponds to a CFRunLoop, > but it doesn't much matter. NSRunLoop is not generally safe to use from any > thread other than the one to which it belongs. So, either the CFRunLoop is > CFRunLoopGetCurrent(), in which case you can use +[NSRunLoop currentRunLoop], > or it isn't and even if you could get the corresponding NSRunLoop you > wouldn't be able to safely do anything with it. > > I don't see any documented guarantee that the source callbacks will be called > on the run loop's thread (as opposed to the thread which called the > scheduling or unscheduling API). In fact, the documentation strongly > suggests that the callbacks are called on the thread which does the > scheduling or unscheduling. > > Are you sure your wrapper class needs to support those callbacks? If so, you > would be better off using CFRunLoop instead of NSRunLoop. > > Regards, > Ken >
Well in this very library there will be multiple classes that can be inserted into the run loop so this class is sort of a boilerplate killer, and it abstracts away the difference between different implementations of Foundation (Cocoa/GNUstep/Cocotron) so that the code written with it can be used on other platforms as well, with minimal changes. (just rewrite a few classes and everything else will just work) _______________________________________________ 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
