Re: module cleanup [3/n]

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Gary V. Vaughan on 9/11/2007 3:44 PM:
>> This adds a refcount builtin to the load module.  I still think it is a
>> bit odd that importing helper symbols from an m4 library affects the
>> symbol table, but didn't see an easy way to fix it as part of this patch.
> 
> I'm not sure I understand you.  Could you explain what you mean by
> 'helper symbol',
> and what 'symbol table' you are referring to?

libgnu's esyscmd does M4_MODULE_IMPORT (m4, m4_set_sysval); in other
words, it needs the m4_set_sysval entry point in libm4.  But in the
process of importing that entry point, it currently ALSO had the side
effect of re-loading all of libm4's builtins into the m4 symbol table.

> 
>> $ m4 -m load
>> refcount(`m4')
>> 1
>> unload(`m4')refcount(`m4') dnl no longer in table
>> 0 dnl no longer in table
>>
>> esyscmd(`echo')
>>
>>
>> refcount(`m4') dnl esyscmd imports from m4 module, reloading macros
>> 1

And that was an example of what I found confusing.  I think that once the
user does unload(`m4'), dnl should not be available until the user does
load(`m4'), even if, in the meantime, they use esyscmd which happens to
rely on entry points available in libm4.  In other words, the libltdl
reference count of libm4 will be one, but the module load count (either
via the refcount builtin that is in CVS right now, or if I rewrite that as
suggested to make the m4modules builtin more powerful, then the number of
times that `m4' appears in the m4modules output) is zero.

> 
> I see no reason to add another arbitrary builtin, where m4modules itself
> can
> easily be extended to provide sufficient functionality.  Let's revert
> this, and
> instead have m4modules list the stack of loaded modules.

OK, I'll work on that next.  It may be another couple days before I post
my 4/n patch.

> 
> If we were to keep the refcount builting, libltdl tracks it for us, so
> there is
> no need to duplicate that code again. The libltdl refcount is retrieved
> with:
> 
>     lt_dlgetinfo(module->handle)->ref_count

Indeed, the lt refcount is what we were using prior to my patch.  However,
as pointed out above, I don't think it is the right count to use.

On the other hand, if I make m4modules track load/unload pairs reliably
(something which libltdl does not do, since it flattens multiply-loaded
modules into a single position in its traversal), then I could use the
m4modules implementation to track refcount rather than having a refcount
member in m4_module.  I'll play with this idea while preparing the patch.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG6TFb84KuGfSFAYARAmM/AJ4mUWiVedm44nxqsPnQMvbhJgoj4QCfSJ3n
GfVrXxUPKW5pcGlh3mhOLRQ=
=VMzt
-----END PGP SIGNATURE-----