Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 19 Feb 2016 17:08:27 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        Eric van Gyzen <vangyzen@FreeBSD.org>, threads@freebsd.org, arch@freebsd.org
Subject:   Re: libthr shared locks
Message-ID:  <20160219150827.GW91220@kib.kiev.ua>
In-Reply-To: <Pine.GSO.4.64.1602182101330.826@sea.ntplx.net>
References:  <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <Pine.GSO.4.64.1602161224250.19440@sea.ntplx.net> <20160217164541.GM91220@kib.kiev.ua> <Pine.GSO.4.64.1602171220540.24204@sea.ntplx.net> <20160218153256.GS91220@kib.kiev.ua> <Pine.GSO.4.64.1602181204470.28877@sea.ntplx.net> <20160219003255.GU91220@kib.kiev.ua> <Pine.GSO.4.64.1602182101330.826@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Feb 18, 2016 at 09:31:44PM -0500, Daniel Eischen wrote:
> 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.

Increasing the structures sizes (and bumping versions) would
- break ABI
- invalidate all the work which was done by people from the FreeBSD 7.x
  time to keep the ABI stable, by writing shims, by adopting changes
  to provide compatibility, and by testing the compatibility
without any benefit of a new feature.  It would be only promised to
provide a new feature sometime in the 11.x scope.

My immediate goal is to get the published patch committed.
After that, I want to look at the implementation of the robust
mutexes.  I hope that this would be done for 11.0, but if not, it
should be mergeable.

The libthr2 stuff, by which I call everything related to inlining,
should be started after that.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160219150827.GW91220>