[squeak-dev] Re: [Vm-dev] Better VM <-> plugin API

Andreas Raab andreas.raab at gmx.de
Sat Nov 22 20:43:27 UTC 2008

Igor Stasenko wrote:
>> Yes. Although, you won't get around doing something about unloading either -
>> we spent today learning about the intricacies of unloading OpenAL32.dll and
>> it turned out to be absolutely crucial to be able to unload our own plugins.
>> A flat shared namespace might have caused some serious issues here.
> Almost anything "might have cause some serious issues", if you don't
> use it wisely (Class become: nil).
> Its not an argument not to use it.

Certainly. And it wasn't an argument not to use it, merely a practical 
point about something that comes up with a flat shared namespace 
(cleaning up that namespace in the face of unloading modules and 
possibly overwriting entries that are now owned by other modules).

>>> doesn't it look like more modular?
>> No. It looks utterly pointless to me. You introduce a plugin that does
>> nothing but looking up and call an atom; what good is that plugin? If you
>> generalize that just a little you have the FFI where you might declare
>> ioFoo() directly and call it. Which of course could be done via atom table
>> too, but I still fail to see how that would be more modular.
> Not a plugin. I mentioned VM code in interp.c. I see little need in
> having such constructs in plugin.
> In VM core, however, there is always a bit of uncertainty - VM forced
> to provide primitive by default (because its a standart one), but on
> different platforms, depending on their capabilities or your intent,
> you may omit putting functionality of some primitives into VM.

Well, that's why we came up with plugins to begin with ;-) So that 
different platforms and different builds can have different sets of 

> Its not the same thing. Currently you have to define a function - with
> implementation or with empty body to make compiler content.
> In example i showed - you can do simpler - just omit binding a
> function to a symbol.

Sure. But it's still a completely contrived example. The stubs are only 
there because once upon a time, in an age long past there weren't VM 
plugins and you couldn't leave out entire plugins from the generated VM 
so the stubs were a necessity. I need to remove these stubs - they are 
completely pointless in this day and age. Thanks for reminding me.

> Take a look at Hydra code, where InterpreterProxy has left with only 3
> functions, and will stay to have 3 functions forever without need in
> extending protocol , because rest functions is obtained dynamicaly
> using name lookup.
> A plugin simply refuse to start without having all requested VM
> functions be non-null. But the trick is, that VM not forced anymore to
> support obsolete stuff of ever-growing InterpreterProxy protocol.

I see - I had understood you wrongly. I thought you were explicitly 
trying to back out of the role of InterpreterProxy as the contract 
(which is not fulfilled if the VM doesn't export all the required 
functions in Hydra) and rather have the plugin code deal with the 
necessary lookups manually.

The way Hydra does the proxy lookup is just fine as far as I am 
concerned. There is no difference from the client's point of view - for 
the plugin writer the proxy remains the contract and the ability to 
selectively allow and deny certain entry points can in fact be helpful 
since it allows a more flexible set of definitions of what is part of a 
particular proxy interface.

   - Andreas

More information about the Squeak-dev mailing list