[Vm-dev] Better VM <-> plugin API

Andreas Raab andreas.raab at gmx.de
Fri Nov 21 17:01:53 UTC 2008


Igor Stasenko wrote:
> I was pretty unhappy with some places in VM, where it loads a function
> from plugin by calling ioLoadFunction...
> Also, even more painful to see when one plugin wants to call another
> plugin function.

Why would it be advantageous to write:

   static sqInt bitBlitAtom = makeAtom('ioBitBlt');
   registerService(bitBlitAtom, (void*) bitBlt);
   bitBltFn = getService(bitBlitAtom);

instead of using

   bitBltFn = ioLoadFunctionFrom("ioBitBlt", "BitBltPlugin");

Is there any reason for making things even more lengthy than they are 
already?

Cheers,
   - Andreas

> IMO things would be much better , if we formalize these things in VM.
> An idea is simple and easy to implement:
> 
> We need only few functions implemented in VM:
> 
> sqInt makeAtom(char * name);  "registers new atom or returns id of
> already existing one"
> 
> sqInt registerService (sqInt atom, void * service);  "associate a
> value with service id"
> sqInt unregisterService(sqInt atom);  "clear association with service
> id (make value=0)"
> 
> And finally,
> 
> void * getService(sqInt atom);
> 
> 
> Now, plugins first, should declare the atoms they would want to use or
> provide. This can be done once at plugin initialization stage, for
> instance:
> 
> static sqInt bitBlitAtom = makeAtom('ioBitBlt');
> 
> Now, after acquiring atom, plugin can register a service fn under this atom:
> 
> registerService(bitBlitAtom, (void*) bitBlt);
> and upon unloading
> unregisterService(bitBlitAtom);
> 
> now, any other plugin can do:
> 
> bitBltFn = getService(bitBlitAtom);
> 
> if (bitBltFn) { bitBltFn( a, b,c blabla); }
> 
> VM maintains a simple list of atom values and list of atom names and
> their numeric correspondence.
> A getService(bitBlitAtom) is very fast, because its simple access by index:
> 
> getService(sqInt atom)
> {
> if (atom>=0 && atom<atomsCount)
>    return atoms[atom];
> return 0;
> }
> 
> 


More information about the Vm-dev mailing list