From owner-freebsd-arch@freebsd.org Fri Feb 19 00:33:02 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 D6C08AABBE7 for ; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) 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 BFD7B145D for ; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BC98FAABBE4; Fri, 19 Feb 2016 00:33:02 +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 BC172AABBE3; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DA7B145B; Fri, 19 Feb 2016 00:33:02 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u1J0Wted021594 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Feb 2016 02:32:55 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u1J0Wted021594 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u1J0Wtdm021593; Fri, 19 Feb 2016 02:32:55 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 19 Feb 2016 02:32:55 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: Eric van Gyzen , threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20160219003255.GU91220@kib.kiev.ua> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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 00:33:03 -0000 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.