---------- Forwarded message ---------- From: Igor Stasenko siguctua@gmail.com Date: 2008/11/21 Subject: Re: [squeak-dev] Better VM <-> plugin API To: "Greg A. Woods, Planix, Inc." woods@planix.ca
2008/11/21 Greg A. Woods; Planix, Inc. woods@planix.ca:
On 21-Nov-2008, at 11:50 AM, 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.
I know very little about the VM, but I agree what you describe is ugly and inelegant, even at a very generic level.
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);
Everything looked good until I got here.
How is another plugin supposed to access this 'bitBlitAtom' handle that is effectively always in the first plugin's private storage and literally (as you've declared it above) also in the other plugin module's private symbol namespace? (i.e. if it's compiled as a "static" variable in the first plugin module then there's no way the second plugin can use the same symbol to refer to the same storage)
Its not in a private storage. When you telling makeAtom(), you receiving an atom id for given name which is shared among all plugins.
To be more clear, i think there is no need in register/unregister functions, instead there could be only single function:
void * setAtomValue(int atom, void* value); which assigns atom new value and returns old one.
Atom values are global and seen throughout VM. There is no privacy of any kind - one plugin can assign value to atom, and other can read value from it, or vice versa.
So, there is 3 functions: makeAtom setAtomValue getAtomValue
if we take an analogy from smalltalk, then its similar to system dictionary with 3 operations:
atom := 'something' asSymbol. "intern new symbol, or get existing one" value := Smalltalk at: atom. "get value" Smalltalk at: atom put: value. "set value"
Perhaps you meant to add a getAtom() function to your API? Then the second plugin would first do:
static sqInt theAtom; theAtom = getAtom("ioBitBlt");
And then it could do the call above as:
if (theAtom != 0) bitBltFn = getService(theAtom);
if (bitBltFn) { bitBltFn( a, b,c blabla); }
-- Greg A. Woods; Planix, Inc. woods@planix.ca
-- Best regards, Igor Stasenko AKA sig.
On 21-Nov-2008, at 4:30 PM, Igor Stasenko wrote:
2008/11/21 Greg A. Woods; Planix, Inc. woods@planix.ca:
How is another plugin supposed to access this 'bitBlitAtom' handle that is effectively always in the first plugin's private storage and literally (as you've declared it above) also in the other plugin module's private symbol namespace? (i.e. if it's compiled as a "static" variable in the first plugin module then there's no way the second plugin can use the same symbol to refer to the same storage)
Its not in a private storage. When you telling makeAtom(), you receiving an atom id for given name which is shared among all plugins.
Perhaps I'm assuming your syntax is literal C code when that is not what you meant?
The code you wrote explicitly defines a _static_ (i.e. private) symbol for storage that only the one compiled source file will be able to see the referenced storage, and only within the scope of the definition.
But I think Andreas Raab hit the nail on the head with his suggested ioLoadFunctionFrom() idea.
2008/11/24 Greg A. Woods; Planix, Inc. woods@planix.ca:
On 21-Nov-2008, at 4:30 PM, Igor Stasenko wrote:
2008/11/21 Greg A. Woods; Planix, Inc. woods@planix.ca:
How is another plugin supposed to access this 'bitBlitAtom' handle that is effectively always in the first plugin's private storage and literally (as you've declared it above) also in the other plugin module's private symbol namespace? (i.e. if it's compiled as a "static" variable in the first plugin module then there's no way the second plugin can use the same symbol to refer to the same storage)
Its not in a private storage. When you telling makeAtom(), you receiving an atom id for given name which is shared among all plugins.
Perhaps I'm assuming your syntax is literal C code when that is not what you meant?
The code you wrote explicitly defines a _static_ (i.e. private) symbol for storage that only the one compiled source file will be able to see the referenced storage, and only within the scope of the definition.
I'm not sure what code you refer to (there was many). A shared namespace , from definition is not private. Any module can access a symbol value by its name. In same way how we using system dictionary in smalltalk.
But I think Andreas Raab hit the nail on the head with his suggested ioLoadFunctionFrom() idea.
The ioLoadFunctionFrom() having static behavior, e.g. no matter how many times you call this function, you'll receive same result for same arguments. Its because, once compiled, an exported symbols values (function/variable pointers) can't change their values anymore.
-- Greg A. Woods; Planix, Inc. woods@planix.ca
squeak-dev@lists.squeakfoundation.org