Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Sep 2014 18:19:43 +0300
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        John Baldwin <jhb@freebsd.org>
Cc:        adrian@freebsd.org, kib@freebsd.org, freebsd-threads@freebsd.org
Subject:   Re: sem_post() performance
Message-ID:  <20140924151943.GM8870@kib.kiev.ua>
In-Reply-To: <8951456.0ca4t8PBR9@ralph.baldwin.cx>
References:  <20140921213742.GA46868@stack.nl> <20140924143104.GK8870@kib.kiev.ua> <20140924144519.GL8870@kib.kiev.ua> <8951456.0ca4t8PBR9@ralph.baldwin.cx>

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