sem_post() performance

[Adrian Chadd]

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 at 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.