Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!julius.cs.uiuc.edu!wuarchive!uunet!usenix!jsq
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: comp.std.unix
Subject: Re: Standards Update, IEEE 1003.4: Real-time Extensions
Message-ID: <502@usenix.ORG>
Date: 11 Sep 90 03:23:35 GMT
References: <481@usenix.ORG> <495@usenix.ORG> <488@usenix.ORG> <491@usenix.ORG> <493@usenix.ORG> <479@usenix.ORG> <497@usenix.ORG>
Sender: jsq@usenix.ORG
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 30
Approved: jsq@usenix.org (Moderator, John Quarterman)
X-Submissions: std-unix@uunet.uu.net

From: jfh@rpp386.cactus.org (John F. Haugh II)

In article <497@usenix.ORG> swart@src.dec.com (Garret Swart) writes:
>I believe in putting lots of interesting stuff in the file system name
>space but I don't believe that semaphores belong there.  The reason
>I don't want to put semaphores in the name space is the same reason
>I don't want to put my program variables in the name space:  I want
>to have lots of them, I want to create and destroy them very quickly
>and I want to operate on them even more quickly.  In other words, the
>granularity is wrong.

There is no requirement that you bind every semaphore handle to
a file system name.  Only that the ability to take a semaphore
handle and create a file system name or take a file system name
entry and retreive a semaphore handle.  This would permit you to
rapidly create and destroy semaphore for private use, as well as
provide an external interface for public use.

There is no restriction in either case as to the speed which you
can perform operations on the handle - file descriptors are
associated with file system name entries in many cases and I've
not seen anyone complain that file descriptors slow the system
down.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson

Volume-Number: Volume 21, Number 96