Re: module cleanup [3/n]

[Gary V. Vaughan]

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: address@hidden
  ( '/           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