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 macrosand 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 sharedmodule - if you try the libtool interface for loading 'foo' first, thenfoo.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 asdynamic as something like apache, so blindly leaving stuff loaded probablyisn'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 themodule 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
`(_~)_
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ M4-discuss mailing list M4-discuss@gnu.org http://lists.gnu.org/mailman/listinfo/m4-discuss
