From owner-freebsd-arch@FreeBSD.ORG Tue Dec 14 03:19:45 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 626A316A4CE for ; Tue, 14 Dec 2004 03:19:45 +0000 (GMT) Received: from zircon.seattle.wa.us (dsl231-043-165.sea1.dsl.speakeasy.net [216.231.43.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 07FF143D58 for ; Tue, 14 Dec 2004 03:19:45 +0000 (GMT) (envelope-from joe@zircon.seattle.wa.us) Received: (qmail 66203 invoked from network); 14 Dec 2004 03:20:20 -0000 Received: from localhost (HELO localhost.zircon.seattle.wa.us) (127.0.0.1) by localhost with SMTP; 14 Dec 2004 03:20:20 -0000 From: Joe Kelsey To: David Schultz In-Reply-To: <20041213233419.GA52130@VARK.MIT.EDU> References: <1102975803.30309.196.camel@zircon.zircon.seattle.wa.us> <41BE15EE.5060704@elischer.org> <1102977591.30309.203.camel@zircon.zircon.seattle.wa.us> <20041213233419.GA52130@VARK.MIT.EDU> Content-Type: text/plain Date: Mon, 13 Dec 2004 19:20:20 -0800 Message-Id: <1102994420.30309.219.camel@zircon.zircon.seattle.wa.us> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit cc: arch@FreeBSD.ORG cc: Julian Elischer Subject: Re: Fixing Posix semaphores X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2004 03:19:45 -0000 On Mon, 2004-12-13 at 18:34 -0500, David Schultz wrote: > On Mon, Dec 13, 2004, Joe Kelsey wrote: > > On Mon, 2004-12-13 at 14:21 -0800, Julian Elischer wrote: > > > > > > Joe Kelsey wrote: > > > > > > >I have a desire to fix posix semaphores in at least 5.3. The current > > > >implementation doesn't actually follow the "spirit" of the standard, > > > >even though it technically qualifies in a somewhat degraded sense. I > > > >refer to the fact that the current implementation treats posix > > > >semaphores as completely contained inside the kernel and essentially > > > >divorced from the filesystem. The true "spirit" of the standard places > > > >the semaphores directly in the file system, similar to named pipes. > > > >However the current implementation treats the supplied "name" as a > > > >14-character identifier, required to begin with a slash and contain no > > > >other slashes. Pretty weak. > > > > > > > >Well, in order to fix this, we need to add file system code and come up > > > >with a new type. I currently have some time to spend on something like > > > >this and am willing to put in whatever effort it takes. Does anyone > > > >want to add their own ideas or requirements? > > > > > > > >I currently run 5.3, but I suppose I could think about running current > > > >at some point in the future. > > > > > > > > > > I don't think that the spirit is to do what you suggest. > > > I have always interpretted it to be a separate namespace. > > > does the posix "mknod" definition mention how to make a semaphore? > > > > POSIX does not define or allow use of mknod to create a named semaphore. > > Only sem_open() can create a named semaphore. The "spirit", as > > implemented in other OS', clearly indicates the use of file system > > names, not the restricted 14-character name used by FreeBSD. For > > instance, Solaris uses file system names. > > Err, I'm pretty sure Solaris uses a separate namespace for > semaphores, and I think Linux does the same. That's not to say > that I'm opposed to this idea. However, the implementation you > propose, while aesthetically pleasing, is likely to be much slower > and take a good deal of effort. Moreover, it doesn't seem that it > would provide any significant additional functionality. The Solaris documentation specifically says that sem_open uses file system namespace. The whole point of POSIX semaphores is that there are TWO different ways to create semaphores. sem_init() creates unnamed semaphores. sem_open creates named semaphores. Therefore, you choose at creation time whether you want speed or interoperability. The speed penalty only applies to creation/open. Once you have the semaphore, the rest is the same. The whole point of having a file system name is to allow for unplanned sharing in a complex way. Using stupid 14-character names does not allow for the use of sub-directories and sym-links and so on to really take advantage of the complex name space. Of course, if no one really wants to see this, then I guess I can just hide over in my little corner since *I* want to see this happen. /Joe