Date: Thu, 18 Feb 2016 21:31:44 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: Eric van Gyzen <vangyzen@FreeBSD.org>, threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <Pine.GSO.4.64.1602182101330.826@sea.ntplx.net> In-Reply-To: <20160219003255.GU91220@kib.kiev.ua> References: <20151223172528.GT3625@kib.kiev.ua> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1602182101330.826>