Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 23 Dec 2015 16:30:58 -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.1512231615220.6659@sea.ntplx.net>
In-Reply-To: <20151223201837.GW3625@kib.kiev.ua>
References:  <20151223172528.GT3625@kib.kiev.ua> <Pine.GSO.4.64.1512231319280.6028@sea.ntplx.net> <20151223190519.GU3625@kib.kiev.ua> <Pine.GSO.4.64.1512231441230.6340@sea.ntplx.net> <20151223201837.GW3625@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Dec 2015, Konstantin Belousov wrote:

> On Wed, Dec 23, 2015 at 02:48:56PM -0500, Daniel Eischen wrote:
>>
>> If the application creates the object itself or allocates storage
>> for it, basically, if it isn't opaque, yes.  But we can bump port
>> revisions for affected libraries (probably just searching
>> /usr/local/include/... for pthread_mutex, pthread_cond, etc
>> types to see possible problems.  I did a search for the installed
>> ports on my system and found a few that might cause problems.
> 
> This relegates the issue to an attempt to do the full rebuild.  But I
> do not see how the port bump would fix it, assume that you are updating
> from the 10.x to 11.x and have the mix of the libraries, some of which
> were built during the 10.x lifetime but with the bumped ports version.
>
> It is not feasible to do a reliable audit of the 24+ Kports.

Is it really that hard to do a port run and insert a grep
for pthread_{mutex,cond,rwlock}_t in a ports installed
header files?  Then just blindly bumping portrevisions
for those ports and those depending on it?

Other than errors caused by storage layouts, libthr can
easily be instrumented to emit a warning when a sync type
is used with the wrong versioned function.

>> I think we're just putting off the inevitable.  Do we not want
>> to change our pthread sync types anyway, to get rid of an extra
>> dereference per lock?  To get rid of the hacks in libc, rtld,
>> etc?
>>
>> If the answer is no, we never want to do that, then ok.
> 
> An answer to this question requires a) consensus b) a workforce that
> would do the decided transition.  I evaluated my opinion, potential
> consequences and efforts required, and ended up with the posted patch.

There's an old patch here:

   http://people.freebsd.org/~davidxu/pshared/patch6.diff

-- 
DE



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