[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
functionality.
> 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.
Cheers,
- Andreas
More information about the Squeak-dev
mailing list
|