[squeak-dev] FFI considered harmless (was: Loading FFI is broken)

Eliot Miranda eliot.miranda at gmail.com
Wed Nov 20 00:12:43 UTC 2013


On Tue, Nov 19, 2013 at 12:00 PM, Bert Freudenberg <bert at freudenbergs.de>wrote:

> On 19.11.2013, at 12:35, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
> > Hi All,
> >
> >     this is an important discussion that is taking a religious tone that
> we should strive to avoid.
>
> Let's call it philosophical, "religious" is just flame bait.
>
> >  There are good arguments for plugins, namely security and
> encapsulation.  There are good arguments for an FFI, namely extensibility
> and platform compatibility.
>
> Agreed.
>
> > [... nice explanation snipped ...]
>
> > A number of straw men have been raised against the FFI in this
> discussion.
>
> No-one has been arguing against FFI in general. We agree an FFI is useful,
> and a more powerful FFI is better. We just (appear to) disagree on how
> widely it should be used.
>
> > Bert asks "Suppose we add a new VM platform, like a VM running on
> JavaScript in the browser. Do you really want to re-implement all the C
> libraries utilized via FFI? Or rather a handful of primitives in your
> language of choice?".  First it is not clear that one *can* implement these
> primitives taking either approach.  If the platform, e.g. JavaScript in a
> browser, takes the Squeak plugin approach of preventing access to the
> platform except through a restricted set of facilities, then certain
> functionality will simply be off-limits, whether one has an FFI or not.
>  Second, reimplementing all the C libraries isn't obligatory.  If the
> platform provides an FFI one simply mates to its FFI and accesses the
> underlying libraries.  If it doesn't then that functionality is off-limits,
> but that doesn't mean the rest of the system doesn't work.
>
> That's where we disagree. If basic functions in the system depend on FFI,
> and FFI is not available, then the system *does not work* at all. E.g.,
> there are efforts in other Squeak forks to replace fundamental parts of the
> system (which currently rely on VM primitives) with FFI calls. That's what
> I am wary of.
>

I see your concern but it doesn't worry me.  I don't see why the system
can't be constructed so that it discovers what services are available.  It
already does that in a number of circumstances.  For example, the menu bar
includes a system report if class SystemReporter is loaded.  So I can
imagine that the socket layer would look for an FFI-based implementation
and use it if available, falling back on the plugin interface if absent.

In these days of build and test slaves this kind of layering is
straight-forward to manage.


One of the fundamental services of a virtual machine is providing a safe
> and complete environment for the system to function in. Plugins enrich that
> environment. But FFI pokes holes into that safe environment, reaching out
> of the virtual world into the "real" world.


> Indeed sometimes that is exactly what you need, namely to better interact
> with the specific host system you are running on. I'm simply saying that we
> need to clearly separate this from the base system, which should be as
> independent of the actual host platform as possible.
>

Again I see this as a straw-man.  Yes, the system should be able to provide
something portable and safe, and feature-rich.  But it should also be able
to provide access to the broader environment if so desired.  Further, if a
superior interface is available via FFI the system should use it over and
above the plugin interface.  The JIT does this, but you'd never notice.  If
sse instructions are available they get used, etc.  The system already
adapts to the underlying host (file directory separators, etc).  Whether
the system is independent of the host or heavily dependent on it is a
matter of perspective.  One perspective is to say that it provides portable
abstractions of host facilities.  Whether one goes through an FFI or a
plugin to provide these abstractions makes little difference.  I would
agree that we keep the FFI separate from /a/ base system, but not form
/all/ base systems.  I want support for symbolic links and I don't want to
depend on a plugin that can't, because the facilities are too different
across platforms, provide a portable abstraction of symbolic links across
unix, windows and mac.  I want to be able to launch an arbitrary external
program and not be limited to a small set of supported programs known by a
plugin, etc, etc.  These are all valid things to have in a base system, but
not valid things to have in e.g. a web plugin.


>
> - Bert -
>
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131119/a9dc8aaa/attachment.htm


More information about the Squeak-dev mailing list