Re: [ANNOUNCE] bare-bones loadlib

[Edgar Toernig <froese@...>]

Luiz Henrique de Figueiredo wrote:
> 
> I'd like to hear about this, that is, about unixes that
> do and that don't support dlfcn, and also about other OSs (Windows, Palm,
> Macintosh, Mac OS X, Acorn RISC OS, EPOC, BeOS, OS/2, ...).

You'll allways find a system that will not support it or where is really
hard.  But does it matter?  The worst thing would be that this system
will not have dynamic loader support.  That's all.  Just give them
a place where they can plug in their dyn-loader routines.

>... I'll then step down and let the community take over.

I take that as a joke *sg*

> > - The API should be like that of loadfile: accept a string and return
> >   a function.  loadlib itself should only load the lib, not execute it.
> 
> I don't really see why this would be more flexible. In the scheme I have in
> mind, the init function that is called when the library is loaded does all
> the work, typically registering functions in Lua. Why would you want to load
> a library and not init it? In any case, this is pretty easy to implement too,
> if it proves to be useful.

For the same reason there's now a lua_loadfile.  A dynamic loaded binary
mustn't be some kind of library with predefined behaviour.  Why make it
different to regular lua files when you can make them look 100% the same?

> > - It should perform some sanity checks like lua_undump (same Lua
> >   version; same number type; ...).
> 
> I don't see how it can do this.

Look at Sol.  A library has this statement:

	SOL_DYNLIB(startfunc);

somewhere in the file.  SOL_DYNLIB is a macro that creates a global
structure with a fixed name initialized with all the stuff you need
to check API incompatibilities and with startfunc.  The loader looks
for this structure, does the tests and returns a cclosure of startfunc.

And when the file is statically linked into Lua the macro would expand
to something different (that's not in Sol).

> > - Unloading should be done by the GC.  It's easy to implement and
> >   requires only minimal support from the Lua core.
> 
> Yes, this is in my TODO list. A general technique for registering clean-up
> functions to be called when a state is closed is to add a userdata to
> the registry and set a GC tag method for it; this function will be called
> when the state is closed.

I meant real garbage collection.  If there's no reference to the dynamic
binary it should be unloaded.  Because the only thing it can export are
functions that's not that difficult.

At the start you only have the startfunc.  All future pushcclosure with
a function from that binary has to be from startfunc or from some function
created by it.  And so on.

So, if one could keep track of a "function creation history" you can
detect when a dynamic binary is no longer in use.  Luckily that's easy *g*
You just keep a reference to the binary in the upvalues:

 - the change to Lua's core: lua_pushcclosure always appends the last
   upvalue of the currently active cclosure to the new cclosure (or nil
   if there is no active cclosure).

 - loadlib creates a userdata containing the handle for that binary.
   A GC call of the userdata will unload the binary.

 - loadlib attaches that userdata as the single upvalue for the created
   cclosure of startfunc.  (Needs a special pushcclosure or a magic
   nupvalue so that lua_pushcclosure will not do its append stuff.)

That's all.  Automatic garbage collection of dynamic loaded binaries.

> > - There should be a unique directory separator.  It would be ugly
> 
> This, and how to specify file name extensions and separator for lists of
> directories to try is plainly the job of the smart user interface to loadlib.

And you get another system dependant place to take care of.

As I said: I think the infrastructure is _much_ more important than the
actual implementation of the low level loader.

> Perhaps we should call the bare bones version _loadlib...

Who wants a _loadlib?  People want a load"some/file" without bothering
whether it's a source, precompiled, builtin or dynamic file.  You don't
make the difference visible for precompiled Lua files.  Why for pre-
compiled C files?  The Lua app won't see a difference anyway.

Ciao, ET.