[erlang-questions] Re: testing asynchronous code

[Matthew Sackman]

On Thu, Apr 22, 2010 at 09:38:21AM +0200, Ulf Wiger wrote:
> The one ordering guarantee that exists is that if P1 sends a
> sequence of messages to P2, they will arrive in the same order
> as they were sent.

Absolutely, and *even* if the VM happens to implement something
stronger, there's no way you should trust it unless it also appears in
some formal semantics. It's pretty well known that the Sun JVM used to
(may still?) implement much stronger semantics than the JLS, leading to
an awful lot of applications which worked fine on the Sun JVM but not on
the IBM JVM which, whilst still compliant, was much less generous with
its guarantees.

In particular, we've always written Rabbit so that the *only* assumption
it makes wrt ordering is the above. There are some interesting other
things that we rely on by inspection of code, say, gen_server: eg, and
this one turns out to be very useful: "if you return 'stop' from some
handle_* callback *and* a reply term, gen_server will wait until *after*
the terminate callback has completed *before* sending the reply", but
things which are in the language itself or the VM, we're very careful to
avoid false assumptions about.

In fact, there are a lot of questions about exit signals being converted
to messages, the ordering thereof (i.e. can the message caused by the
exit signal of a process dying overtake other messages that process has
sent?), what ordering is there on multiple monitors on a process on
process death etc etc, which we just work around, assuming the worst,
given that signals and especially monitors don't seem to be mentioned at
all in the formal semantics as they stand.

Matthew