From owner-freebsd-threads@freebsd.org Wed Dec 23 19:05:27 2015 Return-Path: Delivered-To: freebsd-threads@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 7ED16A4FD84 for ; Wed, 23 Dec 2015 19:05:27 +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 60E631395 for ; Wed, 23 Dec 2015 19:05:27 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 5BF8DA4FD82; Wed, 23 Dec 2015 19:05:27 +0000 (UTC) Delivered-To: threads@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 41499A4FD80; Wed, 23 Dec 2015 19:05:27 +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 DFA551392; Wed, 23 Dec 2015 19:05:26 +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 tBNJ5K4l088363 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 23 Dec 2015 21:05:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua tBNJ5K4l088363 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id tBNJ5JCE088358; Wed, 23 Dec 2015 21:05:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 23 Dec 2015 21:05:19 +0200 From: Konstantin Belousov To: Daniel Eischen Cc: threads@freebsd.org, arch@freebsd.org Subject: Re: libthr shared locks Message-ID: <20151223190519.GU3625@kib.kiev.ua> References: <20151223172528.GT3625@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-threads@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Dec 2015 19:05:27 -0000 On Wed, Dec 23, 2015 at 01:27:35PM -0500, Daniel Eischen wrote: > On Wed, 23 Dec 2015, Konstantin Belousov wrote: > > [ ... ] > > Would the ABI modified to make the pthread_mutex_t large enough to > > hold struct pthread_mutex, the rest of the implementation of the > > shared mutex is relatively trivial, if not already done. > > > > Changing this ABI is very hard. libthr provides the symbol > > versioning, which allows to provide compatible shims for the previous > > ABI variant. But since userspace tends to use the pthread objects in > > the layouts of the library objects, this causes serious ABI issues > > when mixing libraries built against different default versions of > > libthr. > > I think this is only if the libraries (or apps) pass pthread > lock types between them, that one has initialized with one ABI > but the other library uses another ABI. We should really > exclude this as part of our ABI compatibility. Applications commonly embed pthread locks into their objects, including the exposed ABI in the third-party libraries. struct my_object { pthread_mutex_t obj_lock; ... }; Changing the size of the pthread locks causes uncontrolled breakage of the ABI for significant number of third-party code. The issue is similar to the effect of the attempted ino_t expansion to the 64 bit, which changes the struct stat layout and then triggers cascade of the ABI issues. With struct stat, most of it is localized in the src/, which makes handling easier because all of the changed staff is under our control. For libpthread, the approach would cause *big* blow up for ports and for software compiled locally, and we cannot do anything. It would become the flag day, with subtle bugs all over there after the transition on a machine where ABIs are mixed. This is not an issue for e.g. appliance vendors, but IMO is unnaceptable for general-purpose OS. And, why pay the cost of the flag day for the feature that was not present up to today ? > > Mixing libraries built with different pthread ABIs should not > be a problem as long as they don't directly operate on the > other's pthread lock types. > > There is also our ability to do a library version bump as a last > resort. Bumping libthr version would be not enough. It is very much possible to get both libthr.so.3 and libthr.so.4 into the same process. Versions for the symbols must be adjusted to properly bind new and old ABI' consumers. I did evaluated this route, and I am between being very skeptical that it is workable and completely denying the viability. As I pointed out earlier, this causes enormous amount of bugs due to the ABI change in third-party, you cannot mix. Clean recompilation for the new ABI would solve it, but it is not acceptable for FreeBSD pretending to support upgrades.