Re: 329-gary-allow-RTLD_GLOBAL

[Gary V. Vaughan]

On 9 Apr 2007, at 13:03, Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Sun, Apr 08, 2007 at 08:09:23PM CEST:
> > pthread_mutex_t mutex; pthread_mutexattr_t attr;
> > pthread_mutexattr_init(&attr);
> > pthread_mutexattr_setpshared(&attr,PTHREAD_PROCESS_SHARED);
> > pthread_mutex_init(&mutex, &attr); pthread_mutexattr_destroy(&attr);
> > pthread_mutex_destroy(&mutex);
>
> And since you have to do initialization and destruction, you might as
> well use a pointer type, to facilitate ABI + API compatibility, no?
> None of the ltdl API needs to be very time-efficient, a couple of
> mallocs weigh nothing against a dlopen(), so I don't see a good reason
> to do micro-optimization here.  So the only valid arguments I see
> against a pointer to an opaque struct is that of over-engineering,
> which would be valid if we could guarantee to never need to pass more
> state.  Do you think that is the case?

Okay.  There's no reason why we can't make the semantics of  
lt_dlopenflags
(or whatever we call it) unpack all the information to lt__dlhandle (the
most efficient way to store symbol visibility is still using bits of the
existing flags element IMHO), and then free the memory of the user's
temporary object instead of forcing them to remember to free it  
manually.
This has all the advantages of ease of use of the method used in my  
patch
without closing off options for future expansion.  For example,  
instead of
calling lt_dlopenext() a user might choose to:

  int errors = 0;
  lt_dlhandle handle;
  lt_dladvise advise = lt_dladvise_init ();

  if (advise == 0)
    return 1;

  errors += lt_dladvise_ext (advise);

  if (!errors)
    handle = lt_dlopenadvise (name, advise);

  if (!handle)
    ++errors;

  return handle;

Where the implementation of lt_dlopenadvise() looks through the elements
of the struct pointed to by ADVISE; copies anything that needs recording
into the lt__dlhandle object; and, frees the memory used by ADVISE.

We can extend the interface in the future by adding lt_dladvise_xxx
functions.

User's can still check whether the handle was able to act on any advice
they passed it with (for fields where that makes sense):

    if (!lt_dlissymglobal (handle))
      warn();

Then again, I'm now inclined to tidy up those interface elements by
putting them in lt_dlinfo, rather than providing explicit predicate fns,
and using two different paradigms as we do now (in recent alphas):

    /* Read only information pertaining to a loaded module. */
    typedef struct {
      char *    filename;       /* file name */
      char *    name;           /* module name */
      int       ref_count;      /* number of times lt_dlopened minus
                                   number of times lt_dlclosed. */
      int       is_resident:1;  /* the module can't be lt_dlclosed?  */
      int       is_symglobal:1; /* symbols can satisfy later  
modules?  */
      int       is_symlocal:1;  /* symbols are visible only locally?  */
    } lt_dlinfo;

Since we return a read-only pointer to the handle's copy of this data,
we can add new fields in the future without breaking the ABI...

(maybe the :1's are a bad idea in that case, and we should just expose
a bool type?)

Comments?

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