home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!pmafire!mica.inel.gov!ux1!fcom.cc.utah.edu!hellgate.utah.edu!caen!saimiri.primate.wisc.edu!ames!olivea!sgigate!odin!arthur
- From: arthur@sgi.com (Arthur Evans)
- Newsgroups: comp.sys.sgi
- Subject: Re: shared memory arena locks
- Message-ID: <1992Nov5.215821.4789@odin.corp.sgi.com>
- Date: 5 Nov 92 21:58:21 GMT
- References: <Bx81Gx.EBF.2@cs.cmu.edu>
- Sender: news@odin.corp.sgi.com (Net News)
- Reply-To: arthur@chiba.esd.sgi.com (Arthur Evans)
- Organization: Silicon Graphics, Inc.
- Lines: 40
- Nntp-Posting-Host: chiba.esd.sgi.com
-
- In article <Bx81Gx.EBF.2@cs.cmu.edu> drew+@CS.CMU.EDU (Paul Olbrich) writes:
- >At the end of the ussetlock man page it says:
- >
- >> [EBADF] The underlying file descriptor for the lock was closed or
- >> re-used by the application.
- >
- >Does this imply that a new file descriptor is allocated for every lock
- >I create with usnewlock?
-
- I'm fairly sure that the answer is no. Here's what I think is
- going on, although I haven't looked at the code in question and
- I'm going mainly from manual pages at the moment:
-
- When you initialize a shared arena (using usinit(3P)),
- the system opens the user-level semaphore device. The file descriptor
- for this device is then associated with the opaque handle returned by
- usinit(). This is hinted at in the man pages for usinit(), usema(7M),
- and ussetlock(3P), but isn't stated anywhere that I could find.
-
- I believe that the ussetlock() man page is referring to this file
- descriptor.
-
- I'm afraid I don't have an answer for your other question.
-
- -arthur
-
- >Also, in the IRIX programming guide, it says that you can't use
- >message passing and floating point in the same program without
- >compiling with the -f switch.
- >
- >What's the -f switch do? The man pages for cc don't mention it at all.
- >
- >Drew Olbrich
- >drew@cs.cmu.edu
-
-
- --
- "'twas whiskey and bad company
- That made a wretch of me."
- - (traditional Irish ballad)
-