Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Dec 2015 21:05:19 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Daniel Eischen <deischen@freebsd.org>
Cc:        threads@freebsd.org, arch@freebsd.org
Subject:   Re: libthr shared locks
Message-ID:  <20151223190519.GU3625@kib.kiev.ua>
In-Reply-To: <Pine.GSO.4.64.1512231319280.6028@sea.ntplx.net>
References:  <20151223172528.GT3625@kib.kiev.ua> <Pine.GSO.4.64.1512231319280.6028@sea.ntplx.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.



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