libthr shared locks

[Konstantin Belousov]

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.