POSIX semaphores and fork() -- when any process exits, they all lose , access

[Daniel Eischen]

On Thu, 24 Feb 2005, Robert Watson wrote:
>
> I was writing some code to exercise POSIX semaphores this morning, and ran
> into the following issue:
>
> If I create a named POSIX semaphore in a process, then fork(), the
> semaphore appears to be visible to both the parent and child.  However, as
> soon as the child exits, the semaphore disappears from the parent.  This
> seems likely incorrect, although I don't have a copy of the spec in
> question so couldn't say for sure.

  http://www.opengroup.org/onlinepubs/009695399/functions/sem_open.html

> It strikes me that the semaphores
> should either be shared as of exit, with the child and the parent both
> having references to it, or they should remain only with the parent, and
> the childs semaphores should be invalidated/corrupted/something.  No doubt
> POSIX has something to say on the topic.
>
> Looking at the kernel code, it looks like the semaphore code is aware of
> process exit() and exec(), but not fork(), which is probably what leads to
> this behavior.  Since POSIX semaphores in the threaded case involve
> cooperation between the library and kernel to implement, I suspect getting
> the semantics right may require a bit of work.

There shouldn't be anything required in libc or the thread libraries.
Shared semaphore lookups are done in the kernel.  The thread libraries
really only deal with non-named and unshared (*) semaphores.

(*) We don't yet support shared semaphores (or mutexes/CVs) 'cause
    it would cause a big ABI change and probably wreak havoc on
    ports.  This needs to be done, but hopefully only after we
    decide on symbol versioning vs library version bumping (don't
    hijack this thread ;-)).

> Does anyone know what the semantics should be, and/or is interested in
> making our implementation fit those semantics?

I'm not familiar with the kernel bits, but I don't think you
have to be concerned with the thread libraries.

-- 
Dan Eischen