Hi,
On 2022-08-27 11:04:47 -0700, Andres Freund wrote:
> - choice of semaphore API needs to be cleaned up, that should be easy now, but
> I thought that I needed to get a new version out first
Everytime I look at the existing selection code I get confused, which is part
of why I haven't tackled this yet.
If I understand the current logic right, we check for sem_open, sem_init if
and only if PREFERRED_SEMAPHORES is set to UNNAMED_POSIX or NAMED_POSIX (no
template defaults to named). Which also means that we don't link in rt or
pthread if USE_*_POSIX_SEMAPHORES is set directly in the template, as darwin
does.
I read the configure.ac code combined with the templates as resulting in the
following precedence order:
1) windows uses windows semaphores
2) freebsd, linux use unnamed posix semaphores if available
3) macOS < 10.2 uses named semaphores, without linking in rt/pthread
4) macos >= 10.2 uses sysv semaphores
5) sysv semaphores are used
Correct?
Given that Mac OS 10.2 was released in 2002, I think we can safely consider
that unsupported - even prairiedog was a few years younger... :). Given the
downsides of named semaphores and that we apparently haven't used that code in
years, I wonder if we should remove it?
However, there has been a thread about defaulting to named semas on openbsd,
but then Tom benchmarked out that that's not going to fly for performance
reasons ([1]).
FWIW, I did notice that netbsd does have working unnamed semaphores. I don't
know how long ago they were added, but they apparently didn't work quite right
in 2018 [1]. No meaningful performance chance in the main regression tests,
I'll run a concurrent check world comparison in the background...
Should the choice be configurable with meson? I'm inclined to say not for now.
Regards,
Andres
[1] https://postgr.es/m/3010886.1634950831%40sss.pgh.pa.us
[2] http://www.polarhome.com/service/man/?qf=sem_init&tf=2&of=NetBSD&sf=3
