Missing Npth test
gniibe at fsij.org
Wed May 4 12:56:06 CEST 2016
On 05/04/2016 02:36 AM, Werner Koch wrote:
> We need to distinguish between the two cases:
> - fork and exec
> - only fork
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
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
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
> I would we more conservative and do a fix only for AIX.
I understand. Let me see if it works on AIX or not.
More information about the Gnupg-devel