Re: Introspection

[Mike Hearn <mike navi cx>]

On Tue, 11 Jan 2005 05:12:51 +0100, Maciej Katafiasz wrote:
> > * The metadata should be stored as a binary blob in the library.
> >   one idea for finding the metadata is to use a symbol name  
> >   derived from the module name, e.g. the metadata for GTK+ would
> >   be accessible via a symbol like _GTK_METADATA. Using a fixed
> >   symbol name would be problematic when using dlsym() to find
> >   the data. 
> 
> I think we should use common interface for accessing that data, which
> would be then implemented using specific mechanisms. For ELF .so, we
> could just use private section or something like that. For python it'd
> be something created as we go through code, and then merged with rest of
> metadata. There still remains question of activation method though, see
> below.

I think the only feasable way of doing this is to have a dedicated ELF
section. This is complex but the best way forward:

- Variables in ELF ABIs are bad bad bad due to the screwball way ELF is
  designed. Basically if you refer to that variable in a module the size
  of that data is encoded in your binary and a difference in size 
  will cause the linker to bail out.
  
  I guess it you never actually refer to it anywhere except via dlsym
  it might work. But people would ... and then they'd get bitten

- A function that returns the data is the most obvious way forward from
  here but how do you share the possibly large data between processes?
  It has to have some relationship to a disk file for mmap sharing to work.

- Hence, an ELF section: can be any size, can be mapped and therefore
  shared

> Activation and cross-references are going to be tricky, to say the
> least. How do we activate referenced types written in Python? How far
> are we going in support for activating unregistered types? Is
> registering it enough provided we can find it in current metadata repo,
> or is loading .so still in order? I suspect that in order for this to
> stay sane and flexible enough, we will need to move quite a bit of
> responsibility to bindings, and hide that behind pretty interfaces.
> Whatever we do, we should avoid solutions like hardcoding sonames for
> example, if at all possible.
> 
> @Mike Hearn: how does COM do it?

I'm not sure what you're asking here. For activation COM maps globally
unique IDs to DLL names which are expected to export magic symbol names
that when given a COM class ID returns a constructed version of it (kind
of, skipping class factories here). So the actual location of code doesn't
matter too much as there is this additional indirection.

thanks -mike