homepage

Support POSIX semaphore on FreeBSD is recent, optional (eg. disabled by default in FreeBSD 7) and limited (30 semaphores). SYSV should be used instead because they are less limited or more adjustable (at runtime: POSIX semaphore requires to recompile the kernel!).
This issue should fix test_concurrent_futures on FreeBSD 7.2 and 8.0: many tests use more than 30 semaphores. The maximum is test_all_completed_some_already_completed: 52 semaphores.

It looks like SysV semaphores are also preferred on Darwin. So I suppose that Mac OS X would also benefit of this issue. Maybe also other OSes (Solaris?).
See also issue #7272.

Informations about SysV semaphores:
 - functions: semget(), semop(), semctl(), ftok()
 - http://perldoc.perl.org/IPC/SysV.html
 - http://beej.us/guide/bgipc/output/html/multipage/semaphores.html 

Examples of programs using SysV semaphores:
http://firebird.cvs.sourceforge.net/viewvc/firebird/firebird2/src/jrd/isc_sync.cpp?revision=HEAD&view=markup
(Firebird, search "#ifdef USE_SYS5SEMAPHORE" sections)
https://github.com/mono/mono/blob/master/mono/io-layer/shared.c#L501
(Mono)

See also #5725.

See also http://semanchuk.com/philip/sysv_ipc/: "System V IPC for Python - Semaphores, Shared Memory and Message Queues"

Adding, or moving, to SYSV semaphores is very low on the list of things to do. If someone were to provide a patch, I'm sure we could consider it.

More info about FreeBSD.
"sysctl p1003_1b.sem_nsems_max" gives the maximum number of POSIX semaphores (per process? system wide?).
Since FreeBSD 8.1, "sudo sysctl -w p1003_1b.sem_nsems_max=256" can be used to change this limit at runtime.
Before FreeBSD 8.1, SEM_MAX constant should be changed in the kernel source code, and the kernel have to be recompiled. (p1003_1b.sem_nsems_max is not configurable in /etc/sysctl.conf, it is an hardcoded limit).
Before FreeBSD 8.0, the POSIX semaphores are disabled by default: the kernel have to be compiled using P1003_1B_SEMAPHORES option. Extract of sys/conf/NOTES:
#####################################################################
# POSIX P1003.1B
# Real time extensions added in the 1993 POSIX
# _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING
options 	_KPOSIX_PRIORITY_SCHEDULING
# p1003_1b_semaphores are very experimental,
# user should be ready to assist in debugging if problems arise.
options 	P1003_1B_SEMAPHORES
# POSIX message queue
options 	P1003_1B_MQUEUE

#####################################################################

NetBSD.
Extract of the sem_close() manpage
http://www.daemon-systems.org/man/sem_close.3.html
---
STANDARDS
 The sem_open(), sem_close(), and sem_unlink() functions conform to
 ISO/IEC 9945-1:1996 (``POSIX.1'').
HISTORY
 Support for named semaphores first appeared in NetBSD 2.0.
---
Martin wrote on the mailing list:
---
According to
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/kern/uipc_sem.c?rev=1.22&content-type=text/x-cvsweb-markup&only_with_tag=MAIN
SEM_MAX is 128 since 2007, and dynamically adjustable (no reboot).
---
It looks like the sysctl (read/write) option is kern.posix.semmax.

Darwin (Mac OS X).
According to the following email (July 2010), Darwin supports POSIX semaphores and the default limit is 10,000 semaphores.
http://osdir.com/ml/darwin-dev/2010-07/msg00012.html
The limit is configurable via sysctl as kern.posix.sem.max.

OpenBSD.
According to Martin, OpenBSD doesn't implement POSIX semaphores.
---
I don't have an installation of OpenBSD, but...
In FreeBSD, POSIX semaphores are implemented in sys/kern/uipc_sem.c.
In
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/kern/
that file doesn't exist. Also, in FreeBSD's limits.h,
_POSIX_SEM_NSEMS_MAX is defined (surprisingly to 256);
in
http://www.openbsd.org/cgi-bin/cvsweb/~checkout~/src/include/limits.h?rev=1.15;content-type=text/plain
this constant doesn't appear. So ISTM that OpenBSD doesn't implement
POSIX semaphores. IIUC, this means that the multiprocessing module
won't be fully functional, and its tests (and the concurrent.futures
tests) will be skipped.
---

Martin fixed test_concurrent_futures (#10798), this issue can be implemented later.

-1
IMHO, implementing SysV semaphores would be a step backwards, plus the API is a real pain.
I think there's no reason to complicate the code to accomodate such corner cases, especially since the systems that don't support POSIX semaphores will eventually die out...

Agreed with Charles-François.

Charles and Antoine's votes match my own, therefore closing the bug wont fix