Missing Npth test

[NIIBE Yutaka]

On 05/04/2016 02:36 AM, Werner Koch wrote:
> We need to distinguish between the two cases:
> 
>   - fork and exec
>   - only fork

I see.

In general, the concept of "fork" is difficult to be defined (or to be
implemented rationally) with threads.  I think that it is wise to
avoid use of fork in threaded applications if possible.  Good practice
in general is to use fork for limited specific cases like fork+exec,
if not avoidable.

I think that this practice of avoinding fork is also applied to
applications with nPth.  The use of fork is not encouraged at all.  It
is only done in a specific use case like fork+exec.  Daemonize would
be another use case.

It would be best for us to ask users no-use of fork in their
applications and to suggest fork before npth_init and use of posix_spawn.


> In the former case there should be no problem because the semaphore is
> destroyed with the exec.

Yes.  In this case, it is a child which does 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)

If it's a parent process, keep using the non-shared unnamed semaphore
(which is created by pshread=0) is no problem on any POSIX systems, I
suppose.

However, in the particular use case of ours, fork is done to
daemonize, and thus, it is a child process which tries to keep using
the semaphore.  In GNU/Linux, it works, but I think that it's just we
are lucky.  It is completely natural for an implementation of thread
library on some POSIX system not to inherit the resource of non-shared
unnamed semaphore to a child process (because by its definition of
non-shared).  I suspect AIX does this (no inherit of the resource).

> 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.

I understand your point.

I don't assume the forked process has a separate copy of the semaphore
with pshared=1.

Rather, I assume there should be no nPth application which uses fork
in the literal meaning of duplicating the process (including threads
and threads resources).  The limited use cases of fork are: fork+exec,
daemonize, or similar (soon exec or soon exit).

>> 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 understand.  Let me see if it works on AIX or not.
--