Newsgroups: comp.os.mach
Path: utzoo!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!mintaka.lcs.mit.edu!mib
From: mib@geech.ai.mit.edu (Michael I Bushnell)
Subject: Re: message passing & migration
In-Reply-To: timk@cs.qmw.ac.uk's message of 15 Mar 91 14:05:27 GMT
Message-ID: <MIB.91Mar18050418@geech.ai.mit.edu>
Sender: daemon@mintaka.lcs.mit.edu (Lucifer Maleficius)
Organization: Free Software Foundation, Cambridge, MA
References: <2991@redstar.cs.qmw.ac.uk>
Date: 18 Mar 91 05:04:18
Lines: 76

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.

   1 Message passing.  I know about the use of copy-on-write for
   intra-machine message passing, but I never could find any mention
   of using copy-on-reference for large messages sent over a network.
   There's an obvious problem of dependency upon some other machine
   for fetching pages after the message has been received.  a. Is it
   the case that this feature hasn't been implemented - for this and
   perhaps other reasons - and are there any plans to include it?  I
   note that the Chorus developers seem to have decided against
   including a similar feature.

One of the advantages of the Mach scheme over the amoeba scheme is
that the Mach microkernel knows nothing about networks and such.  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.

   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.  

   c.  Could somebody clarify when I can/should/must use out-of-line data as
   opposed to in-line data?  Out-of-line data is useful for scatter/gather, but
   does it have to be used for "large" amounts of data, and is out-of-line
   data always sent copy-on-write (intramachine), and therefore must be
   page-aligned?  What, in practice, do programmers (mostly) do?

You can use it whenever you want.  If it isn't page aligned, or an
integral number of pages, then the receiver will be able to read some
data before/after the data you intended to send, but other than that
it works correctly.  Out-of-line is faster (even if going over a
network) because it reduces the number of copies.  The drawback is
that for small amounts of data, the cost of allocating memory in the
recipient may be larger than the cost of the copy.  Certainly this is
true for less than a page (not to mention the data that peeks
through).

   d.  Can (part of) a region created in receiving a message be sent
   in a further message?

Yes, with "correct" semantics.

   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.

   3 Migration.  The Accent work on process migration doesn't seem to
   have been carried over to Mach.  Are there any plans in this
   direction?  (Accent migration also used copy-on-reference, with a
   residual dependency problem similar to that referred to in 1
   above).  

You'd need to implement a server that supported the task abstraction
and did process migration.  This is more than I want to contemplate
doing, and it would significantly slow the system.  There may be a
better way, but I don't know of one that doesn't involve kernel mods.
I know of no one who is working on this.

	-mib
