mikeash.com pyblog/friday-qa-2012-05-18-a-tour-of-plweakcompatibility-part-i.html comments

Vladimir Pouzanov - 2012-12-30 19:24:01

Sun, 30 Dec 2012 19:24:01 GMT

I wonder if it's possible to make your functions trampoline the same way as dyld lazy symbols (stub_helper/symbolstub1/lazy_symbol -like). Wouldn't that be much more efficient even than dispatch_once?

mikeash - 2012-05-19 13:53:48

Sat, 19 May 2012 13:53:48 GMT

A big goal with this was to make it as simple as possible to incorporate the files into an existing ARC project. By making the files ARC-compatible, this eliminates the need to fiddle with any special compiler flags. It's not a big deal, but the less work the better.

I like your idea with the function pointer, but that would require every entry point to have basically two definitions, one that does the basic fetch-once-and-call, and then a second one that does the actual work. Most of the functions don't directly call a PL function, but do a bit of work and then call through to another function. It's certainly doable, but it seems like a bit of a toss-up to me.

Jonathon Mah - 2012-05-18 22:31:37

Fri, 18 May 2012 22:31:37 GMT

With regard to the latter, my suggestion only applies to your first snippet, unless the own-implementation versions were broken out into separate functions, I suppose. Perhaps a block could be used instead of a separate top-level function...

Jonathon Mah - 2012-05-18 22:07:32

Fri, 18 May 2012 22:07:32 GMT

Hi Mike,

Thanks, this looks really interesting! Why do you a typdef (PLObjectPtr) instead of compiling with -fno-objc-arc? (You can force an error like so:)

#if __has_feature(objc_arc)

#error This file must not be compiled with ARC blah blah

#endif

Also, in my mind it would be cleaner to do the function stuff like this:

dispatch_once(..., ^{

    fptr = dlsym(RTLD_NEXT, "objc_loadWeakRetained") ? : PLLoadWeakRetained;

});

(ternary is up to you; use an if if you like). Then the non-once code simply calls fptr each time.