Re: CFRunLoopRef to NSRunLoop: how?
Re: CFRunLoopRef to NSRunLoop: how?
- Subject: Re: CFRunLoopRef to NSRunLoop: how?
- From: Maxthon Chan <email@hidden>
- Date: Thu, 20 Nov 2014 12:15:18 +0800
> On Nov 20, 2014, at 03:59, Ken Thomases <email@hidden> wrote:
>
> On Nov 19, 2014, at 1:00 PM, Maxthon Chan <email@hidden> 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 (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