Message passing

[Jonathan Shapiro]

   The direction I'm heading with pres/int IPC (and traditional Mach
   IPC already sort of worked this way) is to create sort of a
   "schroedinger's cat" situation: a process can be stopped for page
   faults (or whatever) at various points during message transfer,
   but if some other thread tries to examine or control the thread
   performing the transfer, the transfer is aborted and the process
   reverts to a well-defined state, restarting again from scratch later.

Page faults are events of interest to a modern debugger, including
those page faults associated with message transfer.  Hiding them may
do a disservice to the person running the debugger.  As the author of
one of the current hot debuggers I would hate to lose those events.
They are useful for performance monitoring, among other things.

Losing page faults I could live with.  The Schroedinger's cat approach
seems to violate some things that I think of as correctness
constraints.  Once some of the bytes associated with the message have
actually been transmitted, there is no way to take them back.  If the
debugger subsequently resets the sender in such a way that the message
was retroactively never sent you will get into trouble here.

The more interesting case is where the receiver gets halted midway
through the transfer, in which event the effects of the partial
transfer become visible to the debugger.

If you really want to go down this path, I suggest insisting that
message transfers be atomic to the outside world, including debuggers.
If a debugger stops a process in the middle of a message transfer, the
process should not be seen to stop until the message has been
completely copied.

This corresponds to the model that a program halts between
instructions, not during them.  The program is halted (as seen by the
debugger) either before or after the gate jump associated with the
call, but not halfway through it.

   >   If a single page pushes you over the limit you're
   >   in deeper trouble than that.  In Mach it can be more than one page,
   >   though, so it needs real thought.

   For this I think we can fall back on a notion of "reasonable"
   message sizes. 

Generally speaking I agree with you, but I'm not so concerned about
the effects between client and server.  I'm more concerned about the
consequences for third-party processes whose pages are forced out of
core by the need to allocate the buffer.

Oh. Reading more carefully it sounds like you intend to bill either
the sender or the receiver for the pages.  Then it makes sense to me.

   If a message transfer tries to use too much memory, then one side is
   not being "reasonable" and so the transfer fails.

To whom is such an exception reported?


Jonathan