[Python-Dev] future-proofing vector tables for python APIs: binary-module interoperability (original) (raw)

Luke Kenneth Casson Leighton lkcl at lkcl.net
Sat Jan 24 22:10:41 CET 2009

but basically, not only is this technique nothing new - it's in use in Apache RunTime, FreeDCE, the NT Kernel, the Linux Kernel - but also

This look like simple RPC implemantation.

yep.

If I remember well SUN-RPC assign number to program, function, version.

yep - i forgot about that one: yes, that's another example. this is pretty basic well-understood, well-documented techniques that virtually every large project that requires isolation between components (and an upgrade path) ends up using in one form or another.

the only fly in the ointment will be that putting pointers to PyType_String etc. etc. into a vector table (struct), you end up with an extra de-ref overhead, which is often an argument utilised to do away with vector tables. but - tough: the decision involves getting away from "Hell" to something that makes everyone's lives that much easier, it's an easy decision to make.

surely, that should be the only dll which gets specifically linked against msvcr71.dll (or 90, or... whatever) and it would be even better if that then got named msvcr71.pyd, msvcr90.pyd etc. [SNIP] Yes it is enough to encapsulate memory allocation and file functions into python shared library. The python provide memory allocation functions, but not all modules use them. File functions are hiden by posixmodule and python modules can't use them.

except ... posixmodule gets renamed to ntmodule .... oh, i see what you mean: python modules aren't allowed direct access to msvcrtNN's file functions, they have to go via posixmodule-renamed-to-ntmodule.

so it's still ok.

l.

More information about the Python-Dev mailing list