[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: m4 module loader interface simplifications
From: |
Gary V. Vaughan |
Subject: |
Re: m4 module loader interface simplifications |
Date: |
Tue, 19 Feb 2008 15:10:41 +0800 |
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: address@hidden
( '/ Read my blog: http://blog.azazil.net
/ )= ...and my book: http://sources.redhat.com/autobook
`(_~)_
PGP.sig
Description: This is a digitally signed message part