Re: Please test new NSLock implementation!

[Yavor Doganov]

[I am sorry I did not pay enough attention to this old thread at that
time.  (See https://savannah.gnu.org/bugs/index.php?30766#comment19
for why this is relevant now.)]

At Sun, 6 Sep 2009 17:56:34 +0100,
Richard Frith-Macdonald wrote:
> 1. we don't want to expose internal workings because we don't want  
> developers to start to depend on those internals in such a way that  
> it's hard for us to change things later without breaking existing  
> applications.
> 2. we don't want to expose internal workings because changes to them  
> may break API and mean that apps need to be recompiled.
> 
> Issue 1 is real, but we can't quantify how important it is as it's a  
> amatter of perceptions rather than a true technical issue.  Luckily  
> it's quite easily largely fixable, simply by removing pthread.h form  
> the header and replacing the types from pthread.h with opaque dummy  
> types of the same size, so that there is no temptation for developers  
> to use them directly.  So I did that, though really, I'm not sure that  
> was worth the bother, since the ivars concerned were already clearly  
> marked as private.

As they're marked as @private, there's no way for developers to access
them in subclasses, right?  Only the size matters for the purpose of
subclassing.  So I fail to see what the issue is, and how including a
specific header and using library types in ivars for a *required*
library (configure bails out if pthread is not found) is "exposing
internal workings".

> I guess it's just good to do it to avoid having the extra symbols
> polluting developers namespaces.

I admit I don't understand this.

> Issue 2 is a technical problem ... if someone subclasses one of the
> lock classes, their compiled code is obviously dependent on the size
> of the superclass and if that size changes (eg due to using a
> different pthread implementation) then the size of the superclass
> would change even though the version of the base library is
> unchanged.  So potentially an app linked with one copy of the base
> library would fail to run properly with another copy of the library
> even though it was the same version!

If the different pthread implementation is ABI incompatible, that
would mean that gnustep-base (and anything else using this new pthread
implementation) *must* be rebuilt.  Two different incompatible
implementations on one platform can only coexist if they have
different SONAME.

So, if Base is rebuilt because the size of, say, pthread_mutex_t is
different (i.e. ABI change in pthread), then config.status will
substitute @GS_PTHREAD_MUTEX_T@ to the new value, achieving what
... the compiler would do automatically with David's code before that
change.

If Base is not rebuilt (for whatever reason -- user/distro omission
for example), the opaque type will not help at all, because gs_mutex_t
would still have the wrong size -- it would match the size of
pthread_mutex_t at the time Base was compiled.  The class size will
not match the actual size at runtime, possibly leading to the breakage
the trick was intended to avoid.

In conclusion, I think this change serves no purpose and doesn't make
*anyone's* life easier.  I may be wrong, but it seems to me that using
directly pthread types in ivars does no harm at all, in practice.