Re: module cleanup [3/n]

Gary V. Vaughan Thu, 13 Sep 2007 09:14:11 -0700

Hi Eric,

On Sep 13, 2007, at 1:47 PM, Eric Blake wrote:

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.


Ah yes, now I follow.  Thanks for persevering with me :-)  FWIW, I agree

that a symbol imported at the C level purely for the purposes of providing

support for a builtin from another module shouldn't enforce having the
imported module's builtings loaded at the m4 level.

I think the root of this particular  problem is that there isn't yet
sufficient separation of concerns between modules that are in memory

(courtesy of libltdl) and modules that are fully loaded into the m4 symbol table (courtesy of the m4 module system). Once we have things abstracted

cleanly, it should be a lot easier to load and unload modules at the m4
layer independently of whether libltdl has them in memory at the moment.

I see no reason to add another arbitrary builtin, where m4modules itself caneasily be extended to provide sufficient functionality. Let's revert
this, andinstead 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.


Cool!

If we were to keep the refcount builtin, 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.


After I posted my last mail and poked around in the code to cleanup some
variable names, I realised this.  D'oh!

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.

Hmmm... seems there is room for improvement in libltdl here. However, it

might be easier to to have our m4modules builtin traverse libltdl's

flattened module list once, but output the module name once per (libltdl)

ref_count...

While implementing that, please propose improved semantics for the libltdl

APIs that would have made things easier for m4.

Cheers,
        Gary
--
  ())_.              Email me: [EMAIL PROTECTED]
  ( '/           Read my blog: http://blog.azazil.net
  / )=         ...and my book: http://sources.redhat.com/autobook
`(_~)_      Join my AGLOCO Network: http://www.agloco.com/r/BBBS7912

PGP.sig
Description: This is a digitally signed message part

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

Re: module cleanup [3/n]

Reply via email to