[Vm-dev] Stupidifying FFI/library loading mechanism

Igor Stasenko siguctua at gmail.com
Thu May 26 11:48:42 UTC 2011


Hello,
i am fed up seeing the messages like "FFI can't find a library" or "VM
can't find my plugin".

I think we should trash too clever intrinsic library lookup mechanism
and provide a simple primitive, which
attempts to load a library by given file name & path and if it fails,
give an extended response, why:
- library found, but can't be loaded (because it 64bit while you
running 32 bit), or it can't be found and so on.

It should be up to the user to find and load the library first, and
only after you obtained a valid library
handle, attempt to do FFI calls.

IMO, same should be done to plugin loading mechanism. VM should give
you the paths:
 - what is the current directory
 - what is the directory where VM located

then user code could attempt to load external plugin by specifying one
of these paths or any other to the library which representing plugin.
And only after he knows that library successfully loaded, he could
attempt to use its primitives (or do FFI calls).

The approach is simple:
 - first you making sure that you loaded external module/plugin, then
you start using it. And it is your responsibility to make sure you
loaded it,
not VM's.
This could be done at image startup or at code entry point, or even
inside a generic code which handling a primitive failure.

VM should behave like a stupid idiot:
 - if module with name, which specified in primitive pragma
<primitive: 'foo' module: 'bar' >
not registered already in internal list of VM's modules, it should
fail unconditionally without even trying to load external library.
Even for internal plugins: A user code can handle this error and
instruct VM explicitly to load & initialize
internal plugin, but not implicitly like currently VM does for
internal and external plugins.

If we put a module loading mechanism at image side, it will give us
much more flexibility, and all future/potential problems
with it could be fixed there without touching VM code anymore.

I know that it means quite a lot of work (some named primitives even
assume that they never fail). But i think it is worth it.
Because if it will stay like that, we will always have issues with it,
over and over again.

-- 
Best regards,
Igor Stasenko AKA sig.


More information about the Vm-dev mailing list