[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 329-gary-allow-RTLD_GLOBAL

From: Gary V. Vaughan
Subject: Re: 329-gary-allow-RTLD_GLOBAL
Date: Tue, 10 Apr 2007 15:06:09 +0100

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_mutex_init(&mutex, &attr); pthread_mutexattr_destroy(&attr);

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)

  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

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))

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?)


  ())_.              Email me: address@hidden
  ( '/           Read my blog:
  / )=         ...and my book:
`(_~)_ Join my AGLOCO Network:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]