[gmpi] Re: ABI's / Nutshell
- From: Chris Grigg <gmpi-public@xxxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Thu, 24 Feb 2005 13:55:36 -0800
Tim wrote:
On Wed, Feb 23, 2005 at 12:13:45PM -0800, Chris Grigg wrote:
>The pointer could be
>called "pointer_to_my_functions", but at present it's called
>"vtable".
I like the design, but this naming, I humbly suggest, is a mistake
because of the possibility of confusion with the C++ vtable.
Ok, let's dump the word vtable from the GMPI vernacular. How about
"ftable" or "fntable" (function table) or "mtable" (method table?) or ..?
Ideas?
This would be a good time to do some terminology clarification in
general. Not quite sure how to contribute to that, as I'm not sure
I'm totally following how packaging and lifecycle work, so let me
take a crack at a summary, avoiding language-isms and platform-isms:
***
Plug Packaging and Life Cycle
Every GMPI plug product (instantiable plug class) in the world is
identified by GUID. Plug products are delivered in a designated
package file format allowing one or more plug products per package.
To discover package files, the host inspects a designated folder in
the file system (path is platform dependent). To discover the plug
products contained in a package file, the host reads the package
manifest (metadata).
Every package file has exactly one factory function, whose offset
into the package file is itself found at a known offset. To
instantiate a plug product, the host loads the package file into
memory and executes its factory function, passing in the GUID of the
desired plug product; factory allocates and initializes any static
storage for that plug product; upon return the factory provides the
host with a bundle of function pointers representing the GMPI plug
API for that instance. The host will make all calls into the plug
product instance exclusively via these function pointers. This bundle
does not necessarily conform to any pre-existing platform or compiler
or component architecture calling conventions. One of the function
pointers points to a constructor function, which calls back to the
host to allocate storage for the plug product instance and then
initializes it. The host is able to create any number of
simultaneous instances of a given plug product, though this is
subject to any limitations the author of the plug product (or the
package's factory function) may choose to impose.
Once a plug product instance has been constructed, host makes all
normal operating calls using the bundle of function pointers;
beautiful or ugly music ensues according to taste and talent.
To decommission a plug instance and free its memory, the host calls
the package file's anti-factory function (again via an offset at a
known offset). When the refcount for the corresponding plug product
reaches zero, the anti-factory also frees any static memory used by
the plug product.
***
a) What did I get wrong in the above?
b) How exactly does the factory, or a plug, call back into the host
for services like memory, files, etc.? Doesn't the factory need a
bundle of host callback function pointers too?
c) Is the plug prohibited from calling anything outside itself (other
than the host-provided services callbacks)? If not, since we aren't
using a dynamic linker to load plugs, how exactly are those symbols
(system lib calls etc.) resolved by the time the plug needs to call
them?
-- Chris G.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
- Follow-Ups:
- [gmpi] Re: ABI's / Nutshell
- From: Jeff McClintock
- [gmpi] Re: ABI's / Nutshell
- From: Jeff McClintock
- [gmpi] Re: ABI's / Nutshell
- From: Tim Hockin
- References:
- [gmpi] Re: ABI's
- From: jeffmcc
- [gmpi] Re: ABI's
- From: Chris Grigg
- [gmpi] Re: ABI's
- From: Tim Hockin
Other related posts:
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
- » [gmpi] Re: ABI's / Nutshell
>The pointer could be >called "pointer_to_my_functions", but at present it's called >"vtable".
I like the design, but this naming, I humbly suggest, is a mistake because of the possibility of confusion with the C++ vtable.
Ok, let's dump the word vtable from the GMPI vernacular. How about "ftable" or "fntable" (function table) or "mtable" (method table?) or ..?
Ideas?
- [gmpi] Re: ABI's / Nutshell
- From: Jeff McClintock
- [gmpi] Re: ABI's / Nutshell
- From: Jeff McClintock
- [gmpi] Re: ABI's / Nutshell
- From: Tim Hockin
- [gmpi] Re: ABI's
- From: jeffmcc
- [gmpi] Re: ABI's
- From: Chris Grigg
- [gmpi] Re: ABI's
- From: Tim Hockin