Re: svn commit: r200274 - head/lib/libc/gen
< said: > It's beginning to sound like our POSIX semaphores should be behaving more > like > umtx, which requires only a shared page, and less like file descriptors. Of > course, that would make the global namespace more tricky... Ultimately, the problem is that "POSIX semaphores" are actually three different kinds of object, which just happen to ostensibly use the same programming interface. -GAWollman ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r200274 - head/lib/libc/gen
On Wednesday 09 December 2009 7:24:28 pm Robert Watson wrote: > On Wed, 9 Dec 2009, Andrew Gallatin wrote: > > > John Baldwin wrote: > > > >> 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. > > > > FWIW, this is what confused me. It tends to be kind of a land-mine, since > > programs can be ported from Linux, and appear to work at first for casual > > use. If we don't support pshared, we should return an error from > > sem_init() > > to make it obvious. > > > > Also, perhaps the sem_init() man page should mention sem_open(), since that > > seems to be the only way to really share a semaphore between processes on > > FreeBSD. > > It's beginning to sound like our POSIX semaphores should be behaving more > like > umtx, which requires only a shared page, and less like file descriptors. Of > course, that would make the global namespace more tricky... I believe even that would be tricky since umtx uses the userland address of the umtx as a cookie and that is not guaranteed safe aside from the fork(2) case. Oh, hmm, I'm wrong on that one. You can make a PROCESS_SHARED umtx and it uses the offset relative to the start of the containing vm_object for it's hash key. That's cute. Note that you really only need for the pshared variant. The file descriptors do provide many of the desired semantics (Solaris implements many of the POSIX IPC primitives by mmap()'ing files in /tmp using the provided name for example). One possibility is to make sem_t use the kernel-backed fd-based semaphores for named semaphores and non-pshared semaphores but to use umtx for pshared semaphores. The threads library already does a similar trick where it uses umtx for !pshared semaphores and the kernel for everything else. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r200274 - head/lib/libc/gen
On Wed, 9 Dec 2009, Andrew Gallatin wrote: John Baldwin wrote: 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. FWIW, this is what confused me. It tends to be kind of a land-mine, since programs can be ported from Linux, and appear to work at first for casual use. If we don't support pshared, we should return an error from sem_init() to make it obvious. Also, perhaps the sem_init() man page should mention sem_open(), since that seems to be the only way to really share a semaphore between processes on FreeBSD. It's beginning to sound like our POSIX semaphores should be behaving more like umtx, which requires only a shared page, and less like file descriptors. Of course, that would make the global namespace more tricky... Robert N M Watson Computer Laboratory University of Cambridge ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r200274 - head/lib/libc/gen
John Baldwin wrote: 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. FWIW, this is what confused me. It tends to be kind of a land-mine, since programs can be ported from Linux, and appear to work at first for casual use. If we don't support pshared, we should return an error from sem_init() to make it obvious. Also, perhaps the sem_init() man page should mention sem_open(), since that seems to be the only way to really share a semaphore between processes on FreeBSD. Drew ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r200274 - head/lib/libc/gen
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): 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. 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 ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r200274 - head/lib/libc/gen
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. 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. > 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. -- Jilles Tjoelker ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r200274 - head/lib/libc/gen
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. 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. -- John Baldwin ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r200274 - head/lib/libc/gen
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 Modified: head/lib/libc/gen/sem_init.3 Modified: head/lib/libc/gen/sem_init.3 == --- head/lib/libc/gen/sem_init.3Tue Dec 8 20:47:10 2009 (r200273) +++ head/lib/libc/gen/sem_init.3Tue Dec 8 20:48:06 2009 (r200274) @@ -27,7 +27,7 @@ .\" .\" $FreeBSD$ .\" -.Dd February 15, 2000 +.Dd December 8, 2009 .Dt SEM_INIT 3 .Os .Sh NAME @@ -48,8 +48,7 @@ to have the value .Fa value . A non-zero value for .Fa pshared -specifies a shared semaphore that can be used by multiple processes, which this -implementation is not capable of. +specifies a shared semaphore that can be used by multiple processes. .Pp Following a successful call to .Fn sem_init , @@ -78,8 +77,6 @@ argument exceeds .Dv SEM_VALUE_MAX . .It Bq Er ENOSPC Memory allocation error. -.It Bq Er EPERM -Unable to initialize a shared semaphore. .El .Sh SEE ALSO .Xr sem_destroy 3 , @@ -93,16 +90,10 @@ The .Fn sem_init function conforms to .St -p1003.1-96 . -.Pp -This implementation does not support shared semaphores, and reports this fact -by setting -.Va errno -to -.Er EPERM . -This is perhaps a stretch of the intention of -.Tn POSIX , -but is -compliant, with the caveat that -.Fn sem_init -always reports a permissions error when an attempt to create a shared semaphore -is made. +.Sh BUGS +A sem_t is a pointer to a separately allocated structure, +therefore process shared semaphores only work between related processes +and do not perform very well +(each operation is a system call, +while single-process semaphores only do a system call +if they need to block or wake up a thread). ___ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
