Where the SEM_NSEMS_MAX is defined?

[Ryan S. Arnold]

On Thu, Feb 2, 2012 at 2:05 AM, Neil <freeordie.k@gmail.com> wrote:
> Hi All,
>
> When I read sem_init manual in  POSIX specification, there is a return
> value ENOSPC, which means
>
>  [ENOSPC] A resource required to initialize the semaphore has been
> exhausted, or the
>         limit on semaphores ({SEM_NSEMS_MAX}) has been reached.
>
> But in nptl/sem_init.c, __new_sem_init() doesn't check the resource
> limits. Why it doesn't check and why the implement doesn't in
> according with POSIX spec?
>
> And who should define the const SEM_NSEMS_MAX on linux, kernel or libc?

Hi Neil,

_POSIX_SEM_NSEMS_MAX is defined by GLIBC posix/bits/posix1_lim.h and
installed as a header into include/bits/confname.h.

But.....

I've been looking through the implementation and it seems that the
POSIX specification hasn't kept up with the possibilities available to
the Linux implementation.

You'll notice that on GNU/Linux "[man|info] sem_init" removes ENOSPC
as a possible errno value.

As far as I can tell, on Linux, there's no reason for sem_init () to
ever return ENOSPC.  First of all, sem_init () simply operates on a
sem_t allocated (returned) by sem_open.  In order to return some sort
of information about exceeding _POSIX_SEM_NSEMS_MAX, sem_init would
have to query the sem_t for some invalid state setting, which might be
possible but....

The GLIBC maintainers encourage developers to check return codes and
not rely on GLIBC gracefully handling undefined behavior so sem_init
does no such thing. A failed sem_open results in a sem_t that's set to
SEM_FAILED.  Currently SEM_FAILED (at least on powerpc) is a NULL
pointer.

Passing a SEM_FAILED sem_t to sem_init will crash the program.

So, looking at sem_open, there doesn't seem to be a reason to limit
the number of semaphores to _POSIX_SEM_NSEMS_MAX either.

It seems that the creation of the semaphore (with sem_open) could
certainly fail due to system resource exhaustion (in shmfs perhaps),
but this invalidates the creation of a semaphore and it will return
SEM_FAILED and has nothing to do with some arbitrary hard limit on the
number of semaphores available.

Perhaps _POSIX_SEM_NSEMS_MAX is an artifact of some historical
semaphore pool concept?

Ryan