From owner-freebsd-arch@freebsd.org Fri Feb 19 02:31:52 2016 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 170DCAAD5F8 for ; Fri, 19 Feb 2016 02:31:52 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 026BF1FB5 for ; Fri, 19 Feb 2016 02:31:52 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 017AFAAD5F6; Fri, 19 Feb 2016 02:31:52 +0000 (UTC) Delivered-To: arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F4186AAD5F5; Fri, 19 Feb 2016 02:31:51 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL SHA256 CA - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E9D21FB2; Fri, 19 Feb 2016 02:31:51 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id u1J2VibS010379; Thu, 18 Feb 2016 21:31:44 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Thu, 18 Feb 2016 21:31:44 -0500 (EST) Date: Thu, 18 Feb 2016 21:31:44 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks In-Reply-To: <20160219003255.GU91220@kib.kiev.ua> Message-ID: References: <20151223172528.GT3625@kib.kiev.ua> <56BE69B8.9020808@FreeBSD.org> <56C24586.9050906@FreeBSD.org> <20160216113222.GY91220@kib.kiev.ua> <20160217164541.GM91220@kib.kiev.ua> <20160218153256.GS91220@kib.kiev.ua> <20160219003255.GU91220@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 02:31:52 -0000 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