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>