Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!icdoc!qmw-cs!timk From: timk@cs.qmw.ac.uk (Tim Kindberg) Newsgroups: comp.os.mach Subject: Re: message passing & migration Message-ID: <2994@redstar.cs.qmw.ac.uk> Date: 19 Mar 91 11:26:13 GMT References: <2991@redstar.cs.qmw.ac.uk> Sender: usenet@cs.qmw.ac.uk Lines: 69 Nntp-Posting-Host: aux34 In mib@geech.ai.mit.edu (Michael I Bushnell) writes: >In article <2991@redstar.cs.qmw.ac.uk> timk@cs.qmw.ac.uk (Tim Kindberg) writes: > I have some questions about Mach facilties, and would be very > grateful to hear from anyone with some answers: >I'll do my best. Thanks for your response... >One of the advantages of the Mach scheme over the amoeba scheme is >that the Mach microkernel knows nothing about networks and such. I'm not sure that the kernel's ignorance (keeping things simple) is by itself the justification: it's more that custom network protocol choice, port protection, ecryption etc. policies can go into an extra-kernel activity. But is the performance disadvantage resulting from the extra task switch one that everyone is prepared to accept? >The >netmsgserver, which is responsible for providing inter-machine IPC >(transparently, of course) could use such a technique, but I don't >know if it's been done. Since the data is almost always used, I don't >think you save very much. The V system used to provide two calls - copyto() and copyfrom() - using which a server could selectively read from or write to buffers in the client's address space. The idea was that the server might only need to fetch or write some of the client data, but the client gives it a capability to access any part of its request/result buffer, just in case. Use of copy-on-reference would have a similar rationale. Does anyone know if V still supports this, or have any relevant experience to report? > b. Given that copy-on-reference isn't used, how/when is buffering > done for large messages sent asynchronously across the network? >The current netmsgserver doesn't buffer at all. -so is all the data sent immediately across the network and buffered at the recipient kernel, regardless of quantity and of whether there is a task ready to receive it? Mightn't copy-on-write techniques be used to buffer the data at the sending kernel, until a task does a corresponding receive? > 2 Sending port rights. Is there anyone out there sending port > receive rights in messages? I would very much like to hear about > the application context in which you chose to do this, and how you > found using this mechanism. >Port rights are sent constantly. This is an essential part of the >Mach model. In the GNU multi-server, port rights represent (among >other things) files, and filesystems hand port rights to clients when >they open a file or translate a pathname to a file (for a later stat, >for example). The return port for an RPC is also sent as a port right >in the message header, and apart from some additional atomicity >guarantees, operates like a port right sent in a message. I know about the common case of transmitting sending port *send* rights. I am interested in sending port *receive* rights. A server can send port receive rights in a message in order, for example, to transfer its client(s) to another, less loaded server. Further responses would be very welcome.. -- Tim Kindberg UUCP: timk@qmw-cs.uucp | Computer Science Dept ARPA: timk%cs.qmw.ac.uk@nsfnet-relay.ac.uk | QMW, University of London JANET: timk@uk.ac.qmw.cs | Mile End Road Voice: +44 71 975 5236 (Direct Dial) | London E1 4NS