Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!think.com!mintaka!mintaka.lcs.mit.edu!mib From: mib@geech.ai.mit.edu (Michael I Bushnell) Newsgroups: comp.os.mach Subject: Re: MACH questions.. Message-ID: Date: 19 Feb 91 22:54:49 GMT References: <19089@paperboy.OSF.ORG> Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius) Organization: Free Software Foundation, Cambridge, MA Lines: 81 In-Reply-To: vijay@nixdorf2.osf.org's message of 19 Feb 91 21:03:07 GMT In article <19089@paperboy.OSF.ORG> vijay@nixdorf2.osf.org (Vijay Kumar) writes: Path: mintaka!snorkelwacker.mit.edu!paperboy!nixdorf2.osf.org!vijay From: vijay@nixdorf2.osf.org (Vijay Kumar) Newsgroups: comp.os.mach Date: 19 Feb 91 21:03:07 GMT Sender: news@OSF.ORG Reply-To: vijay@nixdorf2.osf.org (Vijay Kumar) Lines: 69 1. I am having difficulty in understanding the MACH object-oriented construction of distributed systems. The no-senders detection mechanism lets servers detect receive ports for which there are no senders. Of what use is such a detection mechanism? Servers may want to deallocate resources when they are no longer in use. The no senders notification allows server to detect this. Think of the kernel keeping a reference count for each send port, and telling the server when the ref count drops to zero. 2. In the article that I was reading, the authors also say that the mechanism significantly reduces the number of ports used by object-oriented servers, because they do not need to create a notify port for every object port. Clients holding send rights for the object port can not forge no-senders notifications, because the server can distinguish messages sent to send rights. This totally confuses me. Can someone throw some light on this topic? I don't understand this either. Perhaps if you posted a quote from the article? 4. Servers can abort computations on behalf of a dead client by requesting dead-name notifications for the send-once right reply port. In what way is this dead name notification of any importance to the server because it will receive the notification only after the computation completes and also the next thing that a server does (before it receives the dead-name notification) will be to send a reply on the send-once right reply port and it will know about the client's death at that time. The dead-name notification is of no use to the server unless the kernel pre-empts the server and the server does some sort of a stack-rewind operation after it realizes that the client is dead. There are usually several threads within a server. One may be dedicated to receiving the dead-name notification and then stopping the thread processing the request. With a single threaded server, the notificiation is certainly of less value. 5. The new IPC mechanism implemented in Mach 3.0 uses copy-on-write optimization. Basically, when a client task sends a message to a server, the physical pages which contain the client's message are mapped into the server's unused virtual address space. That way, a copy operation is saved and the kernel changes the protection of the shared pages so the a protection violation fault gets kicked of if either one of them modifies data. But later I also read that a send operation has two phases. First, the kernel copies the message into an internal buffer, making out-of-line memory regions copy-on-write. Now why do we need to make the memory regions copy-on-write after it is being copied anyway? I also thought we are avoiding a copy operation, but actually we are not.. When it says "copies into an internal buffer" it means the message and the pointer, but not the out-of-band data itself. 6. Do send and receive ports have two different names? Is the port name some thing like a file descriptor? No. If a task has send rights and receive rights for the same port, the two rights share the same name. A port name is somewhat like a file descriptor, except they are arbitrary 32 bit numbers instead of small integers. -mib