Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!o.gp.cs.cmu.edu!andrew.cmu.edu!+ From: Richard.Draves@cs.cmu.edu Newsgroups: comp.os.mach Subject: Re: mach_port_allocate_name Message-ID: Date: 25 Jun 91 18:38:04 GMT References: Organization: Carnegie Mellon, Pittsburgh, PA Lines: 33 In-Reply-To: Excerpts from netnews.comp.os.mach: 24-Jun-91 mach_port_allocate_name Greg Buzzard) (687) >What is the reason for the mach_port_allcate_name function being in the >kernel interface? It seems to me that all it does (over and above >what mach_port_allocate does) is make implementations more difficult. >That is, this is the only reason that I can think of that would cause >me to use a splay tree in the port name lookup facitily. >Similarly, it seems that it would have been nice if >mach_port_insert_right was restricted to only insert rights using a >"name" that had been previously extracted. >Am I missing some implicit rationale for this interface? In fact, the full 32-bit space for port names is commonly used. Some important servers make use of mach_port_allocate_name to allocate ports which will represent an object, where the name of the port is the address of the object in their address space. When they receive a request message, the conversion from port to object doesn't need a hash table; it is just a cast. If the Mach 3.0 interface were redesigned in a vacuum, it would still be a tough call whether this functionality warrants the increased implementation complexity. However, in real life two factors swayed me. First, earlier versions of Mach support a full 32-bit name space, and backwards-compatibility was an important concern. Second, I was able to design the data structures so the implementation complexity did not slow down the common cases where the splay tree is not accessed. (In the fast cases, port names are an index into an array, and after the array bounds check nothing more need be done.) Rich