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

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

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.

-- 
DE



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