Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Dec 2009 17:42:58 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        Jilles Tjoelker <jilles@stack.nl>
Cc:        svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org
Subject:   Re: svn commit: r200274 - head/lib/libc/gen
Message-ID:  <200912081742.58162.jhb@freebsd.org>
In-Reply-To: <20091208221028.GA57735@stack.nl>
References:  <200912082048.nB8Km6aP099420@svn.freebsd.org> <200912081645.37356.jhb@freebsd.org> <20091208221028.GA57735@stack.nl>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 08 December 2009 5:10:28 pm Jilles Tjoelker wrote:
> On Tue, Dec 08, 2009 at 04:45:37PM -0500, John Baldwin wrote:
> > On Tuesday 08 December 2009 3:48:06 pm Jilles Tjoelker wrote:
> > > Author: jilles
> > > Date: Tue Dec  8 20:48:06 2009
> > > New Revision: 200274
> > > URL: http://svn.freebsd.org/changeset/base/200274
> 
> > > Log:
> > >   sem_init(3): document process shared semaphores and their restrictions
> 
> > I think the other language was more accurate.  The new language has
> > far less detail such as no longer documenting EPERM.
> 
> It seems that EPERM longer happens, at least not for any process-shared
> semaphore at all.

This does seem true.

> What's missing is the SIGSYS/ENOSYS you'll get if sem.ko is not loaded,
> and you're requesting a process-shared semaphore or not linking with
> the threading library.

This is probably less important since it is now enabled by default in HEAD.
I think ENOSYS is a bit of a special case as we don't document it for other
optional services such as SYSV IPC primitives.

> > I think it is also quite accurate to say that the current
> > implementation is not capable of process shared semaphores.  Several
> > things would need to be changed including moving away from using file
> > descriptors.
> 
> There are some lines of code dedicated to make it work, and some people
> seem to use it, although they notice that it does not work very well.
> This topic has come up on the mailing lists several times recently.

No, it doesn't really work.  It happens to work across a fork(), but that is
the only case.  In particular, you can't mmap() a file (or a shared memory
descriptor) and sem_init() a region of it and expect another process to be
able to use it directly via sem_wait() (which is what pshared is supposed to 
mean):

<quote source="Open Group">
If the pshared argument has a non-zero value, then the semaphore is shared 
between processes; in this case, any process that can access the semaphore sem 
can use sem for performing sem_wait(), [TMO] [Option Start] sem_timedwait(), 
[Option End] sem_trywait(), sem_post(), and sem_destroy() operations.
</quote>

The fact that we don't fail attempts to use pshared outright is probably 
dubious.  They cannot possibly work as currently implemented aside from fork() 
since the structure embeds a file descriptor and file descriptor indices are a 
per-process namespace, not a global namespace.

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200912081742.58162.jhb>