🚀 go-pugleaf

In <MIB.91Mar18050418@geech.ai.mit.edu> 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