Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Sep 2014 09:47:49 -0700
From:      Adrian Chadd <adrian@freebsd.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        Konstantin Belousov <kib@freebsd.org>, freebsd-threads@freebsd.org
Subject:   Re: sem_post() performance
Message-ID:  <CAJ-VmomC8tOeP8Wo3_NV=4v4%2BeoyyU6gDDAPMyoR7dwx1HL-Uw@mail.gmail.com>
In-Reply-To: <20140924151943.GM8870@kib.kiev.ua>
References:  <20140921213742.GA46868@stack.nl> <20140924143104.GK8870@kib.kiev.ua> <20140924144519.GL8870@kib.kiev.ua> <8951456.0ca4t8PBR9@ralph.baldwin.cx> <20140924151943.GM8870@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
If we have to break things in a big way, can we at least break them in
a way that makes future work somewhat backwards compatible?

This is all pretty painful looking :(



-a


On 24 September 2014 08:19, Konstantin Belousov <kostikbel@gmail.com> wrote:
> On Wed, Sep 24, 2014 at 11:04:28AM -0400, John Baldwin wrote:
>> On Wednesday, September 24, 2014 05:45:19 PM Konstantin Belousov wrote:
>> > I think it is even worse now. If the application linked against FBSD_1.0
>> > (ksem) semaphores implementation runs on the modern host, it cannot
>> > share semaphore with modern binary.
>>
>> Correct.  We changed sem_t's ABI hence the compat shims IIRC.
> I mean, that new and old semaphores cannot IPC.
>
>>
>> > Since this is not considered significant problem, we can avoid compat
>> > code there as well.
> By compat code I mean the switch on SEM_VERSION, not symversioning the
> libc symbols.
>
>>
>> I think if we leave sem_t alone there is no reason to create new compat
>> shims for this change, but the existing FBSD_1.0 versions have to remain for
>> people using old binaries, yes?
>
> Assume we applied new symver to semaphores which use new binary protocol
> on the existing sem_t, and, to make it reasonable, use old protocol
> when sem_t is accessed by older functions.  Then, old binaries cannot
> IPC with new binaries, although both are dynamically linked to libc.
> IMO this is worse than the problem of different libc versions not
> communicating.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmomC8tOeP8Wo3_NV=4v4%2BeoyyU6gDDAPMyoR7dwx1HL-Uw>