Re: [PATCH] Make ENOSPC not fatal in semaphore creation

On Fri, Oct 29, 2021 at 4:54 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> On Sun, Oct 24, 2021 at 10:50 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> > Sadly, although the attached proof-of-concept patch allows a
> > PREFERRED_SEMAPHORES=FUTEX build to pass tests on macOS (which also
> > lacks native unnamed semas), FreeBSD and Linux (which don't need this
> > but are interesting to test), and it also works on OpenBSD with
> > shared_memory_type=sysv, it doesn't work on OpenBSD with
> > shared_memory_type=mmap (the default). I suspect OpenBSD's futex(2)
> > has a bug: inherited anonymous shared mmap memory seems to confuse it
> > so that wakeups are lost. Arrrgh!
>
> FWIW I'm trying to follow up with the OpenBSD list over here, because
> it'd be nice to get that working:
>
> https://marc.info/?l=openbsd-misc&m=163524454303022&w=2

This has been fixed. So now there are working basic futexes on Linux,
macOS, {Free,Open,Net,Dragonfly}BSD (though capabilities beyond basic
wait/wake vary, as do APIs). So the question is whether it would be
worth trying to do our own futex-based semaphores, as sketched above,
just for the benefit of the OSes where the available built-in
semaphores are of the awkward SysV kind, namely macOS, NetBSD and
OpenBSD. Perhaps we shouldn't waste our time with that, and should
instead plan to use futexes for a more ambitious lwlock rewrite.