Re: [ANNOUNCE] bare-bones loadlib

[Luiz Henrique de Figueiredo <lhf@...>]

>Just my 2 cent:

Thanks for your input. Let me start from the end:

>IMHO, creating such an infrastructure is much more important than the
>actual implementation of the low level dynamic loader.  That seems to
>be relatively easy on todays OSs...

Right. My intention is exactly to try to establish that it is easy to
write a low level dynamic loader for todays OSs. It seems that most unixes
now support dlfcn. 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, ...).

Once we have established that a low level dynamic loader either exists
or can be easily written, then we can move on to discuss a more convenient
user interface. As a writer of core tools, I'll then step down and let the
community take over.

> - 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.

> - It should perform some sanity checks like lua_undump (same Lua
>   version; same number type; ...).

I don't see how it can do this. All this info is in lua.h, but how can we
make sure that the library has been compiled with the same lua.h as the
Lua client that is loadling it? The info is not available at runtime.
Perhaps it should. Just to be clear: even without messing with dynamic
libraries, there is today no way to tell whether a library say in object
format is compatible with a given Lua installation. Or is there?

> - It should be possible to loadlib the same file multiple times.  Works
>   with dl_open (has a ref-count).  The lib should assume that all
>   loaded instances share the same static data/bss.

If so, then the init function can keep track of whether it has been called.
On the other hand, you might want to call init again, using a different
Lua state.

> - 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. Perhaps something similar could be done for
handling GC at other times, though I can't think of anything right now.

> - 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.
Perhaps we should call the bare bones version _loadlib...

Here is a minimal implementation for the smart version:

 local _loadlib=loadlib

 function loadlib(lib,init,path,del)
  local i,j=nil,0
  local pat="(.-)"..del
  init = init or lib.."_start"
  local a
  path=path..del
  while 1 do
   local p
   i,j,p=strfind(path,pat,j+1) 
   if i==nil then break end
   p=p..del..lib..".so"
   a={_loadlib(p,init)}
   if a[1]~=nil then myfunc() return unpack(a) end
  end
  return nil
 end

--lhf