libthr shared locks

[Daniel Eischen]

On Fri, 19 Feb 2016, Konstantin Belousov wrote:

> On Thu, Feb 18, 2016 at 12:09:59PM -0500, Daniel Eischen wrote:
>> On Thu, 18 Feb 2016, Konstantin Belousov wrote:
>>> But base system provides C++ runtime for ports and I suspect that libc++
>>> depends on the libthr ABI. Even jemalloc depends on libthr ABI. So
>>> changing only the base ABI is probably impossible, from the first look
>>> the switch like WITH_LIBTHR2_DEFAULT would be a flag day. Anyway, this
>>> must be considered carefully during the later stage of the libthr2
>>> development, right now it is rather empty speculation on my side.
> This paragraph is relevant for my answer below.
>
>>
>> I would think partially inlined objects (still a pointer inside)
>> could be made in libthr (not libthr2) by default for 11.0 (or 11.x).
>> So that the only change is the size of the objects, not anything
>> else.  The only breakage would be layout related.
>
> Structure size is part of the library ABI, when the structure is exposed
> to user, it cannot be increased without consequences.
>
> Changing the size of the libthr objects changes layout of the objects
> embedding the locks.  Doing
> 	class MyLock {
> 	private:
> 		pthread_mutex_t m_lock;
> 		const char *name;
> 	};
> is the common and very popular practice. With the change proposed to
> libthr.so.3, you get subtle and sudden ABI breakage for all libthr
> consumers as well. In particular, it would affect libc (jemalloc) and
> libc++. Depending on the variant of headers used for the compilation,
> you get different layout for user structures.

libc is part of FreeBSD, so it would be recompiled for the new
size.  I was also assuming library version bumps.

-- 
DE