Missing Npth test

[Werner Koch]

On Tue,  3 May 2016 11:03, gniibe at fsij.org said:

> I understand the issue.  Here, the unnamed semaphore created by a
> parent with sem_init(pshared=0) is used by its children.  POSIX-wise,
> this usage of semaphore is undefined.  In GNU/Linux (and possibly

We need to distinguish between the two cases:

  - fork and exec
  - only fork

In the former case there should be no problem because the semaphore is
destroyed with the exec.  In the latter case, where we only fork, we
have a copy of the semaphore and it is not clear whether we need to
re-initialize it (sem_init) or should not do so (or use sem_destroy
followed by sem_init).  It seems we rely on undefined behaviour after
the fork (this is similar to Pthread's mutex problem after fork)

Each nPth enabled process requires its own semaphore (the sceptre
variable in npth.c) and this one must not be shared.  If we would share
a semaphore between processes, we can run into a deadlock.  Thus I doubt
that setting pshared=1 and using fork is a valid solution.  Although the
specs say that a shared memory mechanism needs to be used with pshared=1
it does not guarantee that the semaphore is local to the process and
that the forked process indeed has a separate copy of the semaphore.

> For other systems, it sounds better to create the unnamed semaphore with
> pshared=1.

I would we more conservative and do a fix only for AIX.

> I don't think sem_open is good when we have another option, because
> such a semaphore can be accessed by other processes (while unnamed
> semaphre can only share among a process and its descendants).

Agreed.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.