[KinoSearch] Towards a stable C API... via indirect dispatch

[Aaron Crane]

Marvin Humphrey writes:
>   object->vtable[offset](object)
> 
> Here's how an actual pound-define might look:
> 
>   #define Kino_Term_Destroy(self) \
>       ((kino_Obj_destroy_t)((self)->_[kino_Term_destroy_OFFSET]) ((kino_Obj*)self))

Sounds to me like a reasonable tradeoff between flexibility and
performance, especially given how low the measured performance impact
is.

> The array of function pointers will have to be implemented as an
> array of void*,

Theoretically, object pointers (including void pointers) and function
pointers are incommensurate according to the C standard -- you get
undefined behaviour when you cast between them.  Situations like this
are meant to be handled by picking an arbitrary function-pointer type
to store in the vtable array:

  typedef void (*kino_method_t)(kino_Obj *);

You still have to cast back to the correct type before calling through
such a pointer, of course.

That said, I don't know if any Perl-capable platforms will demonstrate
actual breakage if you cast a function pointer to a void pointer and
back again.  Either way, using the arbitrary-function-pointer approach
is more portable, and doesn't seem to have any significant cost
associated with it.

> Say we remove the Kino_Term_Destroy method... then this code
> will crash at run-time, because the kino_Term_destroy_OFFSET
> symbol cannot be resolved:
> 
>    destroy_meth = self->_[kino_Term_destroy_OFFSET];
> 
> Of course a run-time crash would be bad -- but that just means that
> we can't redact public methods -- which we wouldn't be doing anyway.

More specifically, the failure would be at link-time, right?  Unless
I'm misunderstanding, code using the new macro will contain a reference
to the kino_Term_destroy_OFFSET symbol, so the linker should fail when
trying to resolve uses of that symbol in callers.  Of course, assuming
that most uses of the Kinosearch code rely on a dynamically loaded
KinoSearch.so (or local equivalent), that turns out to be roughly the
same thing as run-time anyway.

-- 
Aaron Crane

_______________________________________________
KinoSearch mailing list
KinoSearch at rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch