Message passing

[Jonathan Shapiro]

   Perhaps the message passing design can take a idea from the 370
   instruction set here.  The 370 has an instruction, Move Long, that
   can copy up to 16 meg of data (The size of virtual memory)...

This particular instruction is one of the major impediments in
building a decently fast 370 implementation.  It ties up an amazing
number of system resources, and is empirically no faster than a
cleverly written string move routine on a modern machine.  RISC
designers abandoned it with good reason, and I'm sort of loathe to
reintroduce it.

In spite of my bias, it's a suggestion well worth considering.


I grant, though, that the same things you do in a 370 debugger to
handle this instruction could be applied to DIMSUM.  I suppose a
debugger could live with the fact that process memory within the
receive buffer is subject to change without notice if the process is
waiting on a message.

If we take this view, then speaking as a debugger author I want the
kernel to provide an event of interest that is guaranteed to be after
the message is completely transferred but before the process has
executed any instructions following the receipt of the message.  [Term
definition: "event of interest" goes back to the work on the UNIX
debugger at AT&T. It refers to any event in the process's execution at
which the debugger is able to get a notification that something
happened.  In a well-designed debugging interface, the process can be
halted on any event of interest.  An "event of interest" is alsy a
synch point in the process model, in that the process state according
to the process model must be well defined at any event of interest.]

Given such an event, I can live with the mutating buffer.  I'm still
concerned about pinning resources.



Jonathan