libtool-patches
[Top][All Lists]
Advanced

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

Re: 329-gary-allow-RTLD_GLOBAL


From: Ralf Wildenhues
Subject: Re: 329-gary-allow-RTLD_GLOBAL
Date: Mon, 9 Apr 2007 14:03:38 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

* Bob Friesenhahn wrote on Sun, Apr 08, 2007 at 08:09:23PM CEST:
> On Sun, 8 Apr 2007, Ralf Wildenhues wrote:
> >
> >But this is how it can be extended without breaking API!  Only if
> >lt_dlopaque is a pointer type, of course, and also you need to free the
> >object later on.
> >
> >And IIUC then this is how pthread works, too, no?
> 
> The pthread interfaces don't assume that the object is a pointer so 
> they work differently than suggested.  Pointers are error prone so 
> they are best reserved for internal library interfaces if possible. 

Wait.  If you have a pointer to a struct, then you have as much type
safety as you can get with C.

> The implementation is free to embed pointers in the API object.

If you don't pass pointers, then changing the object (e.g., its size)
will incompatibly change the ABI.  Only the API will remain compatible.

> Given these pthread interfaces:
> 
>      int pthread_mutexattr_init(pthread_mutexattr_t *attr);
> 
>      int pthread_mutexattr_destroy(pthread_mutexattr_t *attr);
> 
>      int pthread_mutexattr_setpshared(pthread_mutexattr_t  *attr,
>      int pshared);
> 
>      int pthread_mutex_init(pthread_mutex_t *mutex, const
>      pthread_mutexattr_t *attr);
> 
>      int pthread_mutex_destroy(pthread_mutex_t *mutex);
> 
> This is now they would be used
> 
> 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?

Cheers,
Ralf




reply via email to

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