Re: m4 module loader interface simplifications

Hi Eric,

On 19 Feb 2008, at 01:04, Eric Blake wrote:
> According to Gary V. Vaughan on 2/17/2008 3:46 AM:
> | I think we should abstract away the difference between {s,}include  
> of an
> | m4 file and of a dso, and do away with load/unload altogether.  It's
> | perfectly possible to keep track of which builtins are still  
> attached to
> | m4 macros, and to unload a module again once it no longer provides  
> any
> | code that can still be accessed... but, even that I think is
> | unnecessary.
>
> Interesting idea.  But can it be error-proof?  In other words, if  
> you use
> include(`foo.m4'), how do we distinguish between text files with  
> macros
> and binary files with dynamic module content?

Look for non-ASCII characters in the first few 10's of bytes?  On some
arch's we can check a file for the ELF magic number.

> Suppose the user has
> M4PATH=dir1:dir2, where dir1/foo is text and dir2/foo.so is a shared
> module - if you try the libtool interface for loading 'foo' first,  
> then
> foo.so will be loaded rather than dir1/foo.

Good point.  We certainly need to be careful to honour the directory  
search
order, but that shouldn't be a problem technically.

> |  After all, why would someone load  a module in the first
> | place if they don't want to use the code it provides?
>
> If m4 is used in a long-running process, then unloading unneeded dso's
> provides better memory usage.  But I don't if m4 will ever be quite as
> dynamic as something like apache, so blindly leaving stuff loaded  
> probably
> isn't an issue for m4.

That's my thought too.  Maybe we can garbage collect unused modules and
throw them out of memory in a later patch.  That will involve a bit more
book keeping at run time than I want to do in this first patch.

> | This in turn opens the possibility of mixed dso/m4 modules.  Such a
> | module would be a directory named after the module containing m4  
> files,
> | one of which should have a predictable name (__init__.m4{,f} a la
> | python?  or an m4 file with the same name as the containing  
> directory?)
> | that
> | runs when the module is loaded, and can pull in code from other  
> files in
> | that module.
>
> So you're proposing the extension of include(`dir') being equivalent  
> to
> include(`dir/file'), where file is either a predictably named text  
> file or
> predictably named dso?  At which point, you name `dir' according to  
> the
> module it is providing?

Exactly.

> Seems reasonable.  It would be interesting to see
> code along these lines, to help decide how maintainable this approach
> would be.


Cool.  I'll see what I can put together over the next few days.

Cheers,
	Gary
-- 
   ())_.              Email me: [email protected]
   ( '/           Read my blog: http://blog.azazil.net
   / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_

_______________________________________________
M4-discuss mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/m4-discuss