[Vm-dev] Cog: A question about: setInterruptCheckChain()

[Igor Stasenko]

On 29 September 2010 23:03, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Wed, Sep 29, 2010 at 12:22 PM, Andreas Raab <andreas.raab at gmx.de> wrote:
>>
>> On 9/29/2010 11:53 AM, Nicolas Cellier wrote:
>>>
>>> Another aspect of the trade-off is releasing creativity.
>>> To change the VM you need advanced skills in both:
>>> - Smalltalk VM internals
>>> - and external libraries you want to use.
>>> That resticts dramatically the list of creators.
>>>
>>> Plus, the difficulties for sharing your creation, you shall distribute:
>>> - either a binary version, but this means users cannot have a mixture
>>> of different features if those require a core modification,
>>> - or VMMaker patches but your audience will shrink again.
>>
>> That's why we have plugins. Keeping the core of the VM as small as possible is most definitely a Very Good Thing and not what's being discussed here.
>
> I think it /is/, and you shouldn't allow your disinclination for the FFI approach blind you to the fact that one way of keeping the VM small is to produce a really strong flexible FFI that supports threading and callbacks and to implement interfaces above the line.  Do you seriously believe things like the ODBC connect should be implemented in plugins?
>>
>> What's being discussed here is if (from that point on) one should provide layers of abstractions via plugins or if one should just expose the image directly to all of the idiosyncrasies of the platform, handing it pointers and let it make FFI calls.
>
> In the case of event callbacks its a different issue.  The current event queue abstraction is broken in that it prevents Smalltalk code from answering questions asked through events such as WM_QUERYENDSESSION because the VM is forced to queue events, and hence can only provide a default answer in the window proc.  So there are areas where having proper callbacks is required to be able to integrate properly with the host operating system.
> I don't disagree with what you say about plugins, or about maintaining cross-platform abstractions in the VM for core functionality that is common across platforms, but I think its clear one needs true callbacks, and that at least for integrating with the GUI this is the best way to implement it.
>
>> It really is a matter of where you want to deal with certain aspects of the system. I prefer to deal with that level of stuff in a plugin via C because:
>> + it provides a way to do ensure memory safety
>
> there's nothing in plugins per-se to maintain memory safety.  A mistake in a plugin is as destructive as a mistake in an FFI call.  In either case a wrapper around a particular call can validate and provide safety.
>
>>
>> + it provides a way to provide abstractions
>
> - so does Smalltalk, and t least in SMalltalk we have inheritance to enable us to express cross-platform APIs in abstract classes and map these down onto particular platforms in concrete subclasses.  This is /far better/ than the sprawling mess that is the platforms tree in the VM.
>
>>
>> + the code is faster to write and debug in C
>
> this is debatable.  In the VW FFI with the ability to catch exceptions and pass them back up (doesn't always work, a bad emory corruption may crash the entire system) makes thing easier.  But low-level debugging is painful in general.
>
>>
>> + access to facilities (threads, interrupts, atomicity) not available otherwise
>
> Again, a strong FFI provides at least some of these facilities.  Not everything can be done through the FFI, but a lot can be done, and elegantly and extensibly, by Smalltalk programmers, not a few VM specialists.
>>
>> On the downside, there is:
>> - it's harder to modify for people who don't know C and are not set up to build a plugin
>> - it's often aimed at the smallest common denominator (though not necessarily)
>
>
> - it is a far more fixed interface that is far harder to evolve
>

Eliot, i don't know what to say in addition. I have same thoughts as you.

Its not a question, that VM should provide a default platform
abstraction layer(s).
But the question, how i can make part's of it optional, or easily
alter/replace them with own implementation (either plugin of ffi)
in case of need, without the need of shipping of own, custom built VM?

Where ends a VM's mandatory functionality and starts an optional one?
a) providing UI & event handling?
  Apparently not for those who wants to run VM as GUI-less
command-line tool or implement own GUI framework.
b) providing a network layer?
  Apparently not for those, who not using network in their
application(s), and instead want to make sure that no network
  activity possible. Or again, wants to provide own network layer.

FFI is not a silver bullet. But my point is not putting you before
choice: use C or FFI.
Its about making VM more flexible at run-time, not at compile time.

> best,
> Eliot


-- 
Best regards,
Igor Stasenko AKA sig.