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

[Eliot Miranda]

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

best,
Eliot


> Cheers,
>  - Andreas
>
>
>  On the other hand, a VM providing a larger de facto immutable API:
>> - somehow is more secure (a guaranty we can run very old images in
>> very new OSes).
>> - can maintain the illusion that despite the efforts of OS and
>> hardware designers to make it ever more complex, a single person can
>> still understand (almost) the whole system.
>> - avoid the necessity to embed knowledge of dozens of different
>> variants of different OSes in your image.
>>
>> Of course, the complexity still exists under the carpet... When I
>> contemplate all the unecessary complex knowledge from those beautiful
>> configure/cmake scripts and macros, I'm not convinced all this cruft
>> will be easier to modify in Smalltalk than it is in C world.
>>
>> I perfectly understand too the desire of a VM maintainer to lighten
>> the burden ;) though.
>>
>> Nicolas
>>
>> 2010/9/29 Eliot Miranda<eliot.miranda at gmail.com>:
>>
>>>
>>>
>>>
>>> On Wed, Sep 29, 2010 at 10:22 AM, Andreas Raab<andreas.raab at gmx.de>
>>>  wrote:
>>>
>>>>
>>>> On 9/29/2010 9:36 AM, Eliot Miranda wrote:
>>>>
>>>>>
>>>>>    See the recordMouseEvent() and its friends (sqNextEventPut,
>>>>>    eventBuffer[1024] ...) in sqWin32Window, for better understanding my
>>>>>    point :)
>>>>>
>>>>>
>>>>> Which makes my point well.  These are simply maintaining a queue.  If
>>>>> one has callbacks then the bulk of the Windows event handling system
>>>>> can
>>>>> be lifted up into the image.  This is what Vassili Bykov did in
>>>>> Newspeak
>>>>> above my Alien callbacks.  In Newspeak the Windows MainWndProc is a
>>>>> callback:
>>>>>
>>>>
>>>> Thus losing any level of platform abstraction. A bad trade-off, IMO.
>>>>
>>>
>>> The platform abstraction merely moves from the VM to classes in the
>>> image.  But it does mean that one can properly implement Windows event
>>> semantics (things like query quit events) that the queue prevents.  And it
>>> means that the VM gets simpler and complexity is handled by better
>>> facilities (in Smalltalk with its many advantages for creating and
>>> maintaining abstractions with concrete variant implementations).
>>> But you and I have had this discussion a number of times and I take your
>>> point about the VM maintaining a black-box abstraction boundary whereas the
>>> in-image implementation is in theory porous.  As I've said before this
>>> doesn't strike me as that important when Smalltalk has had boundary
>>> violators such as instVarAt:[put:] for ever and they are rarely abused.  If
>>> one were to implement a native GUI event interface in Smalltalk using
>>> callbacks one would have to police the abstraction boundary.  But that's
>>> easily done, and there are other benefits
>>> - the VM, being simpler, gets more longevity since changing the event
>>> interface doesn't imply a VM change
>>> - the system, having native interfaces, can support each platform's
>>> facilities in full instead of providing the lowest common denominator
>>> So IMO it is a good trade-off.
>>> best
>>> Eliot
>>>
>>>>
>>>> Cheers,
>>>>  - Andreas
>>>>
>>>
>>>
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100929/567b7c39/attachment-0001.htm