Message passing

[Bryan Ford]

>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.

You can still monitor all page faults, through the external pager interface.

>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.

I agree that there are some "unconventional" effects, but I don't see
what harm they can cause except in extremely obscure corner cases that
can easily be "defined away".  For example, the fully-atomic model
technically allows a process to "change its mind" about the sending
of a message, up to the point at which the message is atomically
transferred, and be assured that none of the message will be seen
by the other side.  The non-atomic model doesn't support that, but
that shouldn't be a problem in practice - you just define the mechanism
such that if you ever try to send a message to someone, any or all of
its contents may be immediately made available to the other side
even if the message transfer is aborted.  Similarly, on the receive
side, you simply define the contents of receive buffers to be
"undefined and arbitrarily changeable" while a process is waiting
to receive a message.  In practice, should be no problem.

>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.

I may do it that way, but so far you haven't given me any convincing
arguments indicating that fully-atomic behavior is valuable. :-)
And it would certainly complicate the implementation.

>   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?

For asynchronous messages or RPC requests, the sender.
For RPC replies, I'm not sure yet - suggestions are welcome. :-)

				Bryan