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
