[Vm-dev] Stupidifying FFI/library loading mechanism

Igor Stasenko siguctua at gmail.com
Thu May 26 12:39:52 UTC 2011


On 26 May 2011 14:16, David T. Lewis <lewis at mail.msen.com> wrote:
>
> I am not sure if it applies to your proposal here, but just in
> case I want to mention one note of caution. The #primLoadModule
> that was discussed previously in the "Sandbox" thread will not
> work on a 64-bit platform, for the same reason that FFI does not
> work on a 64-bit platform.
>
Sorry, i din't followed that issue (cant remember). The reason because
of mixing 32/64bit libraries, or something else?

The primitive you mentioning reusing the same routine to load external module
as VM internally for primitives do. So, it is step in right direction
(explicitly instruct VM to load modules),
but more work needs to be done.

Now imagine that you have a primitives:

loadInternalModule: moduleName
loadExternalModule: moduleName path: pathToModuleLibrary

and by analogy, for FFI:

loadExternalLibrary: pathToExternalLibrary

and in case of failure, these prims could then give you an extended response:
 - module already loaded
 - internal module not exists
 - external library file not found
 - external library file found but cannot be loaded (not a library,
mix 64/32bit mode etc)
 - module loaded but failed to initialize
.. etc

Then you can easily diagnose the problems per each attempt to load some library.
But not like today.. if you telling to load module named 'GL' , VM
tries all different combinations
like
libGL.so GL.so
libGL.dynlib
multiplied on various crazy locations in file system..

Is it only me who thinks that, this looks like shooting blindly into
the sky hoping there are enough ducks flying so you can hit one?

Also, if you explicitly control the module loading then you can also
control which module takes priority
- internal or external one.

if you know, today's VMs first attempting to load external library
with given name, and only then internal plugins.

Apparently, if you wanna play games in sandbox, you'd be willing to
change a priority or even do not attempt to use
any external modules at all.

-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list