[e-lang] [Fwd: Re: [Fwd: Re: Proposal: E / Erlang integration]]

Mark S. Miller markm at cs.jhu.edu
Fri Jun 9 02:47:49 EDT 2006

-------- Original Message --------
Subject: Re: [e-lang] [Fwd: Re:  Proposal: E / Erlang integration]
Date: Fri, 09 Jun 2006 07:54:06 +0200
From: Ulf Wiger <ulf -at- wiger.net>
Organization: Wiger.net
To: david.nospam.hopwood -at- blueyonder.co.uk, erlang-questions -at- 
erlang.org,   "Discussion of E and other capability languages" <e-lang -at- 

Den 2006-06-09 06:35:37 skrev David Hopwood
<david.nospam.hopwood -at- blueyonder.co.uk>:

> Actually, it can't quite be done this way because messages
> received in the waiting state would cause a crash (and it
> is not correct to ignore them).

Yes, this is the problem.

If one may receive input from multiple, uncoordinated senders, there is no
way to predict the order in which the inputs will arrive. So you either
explicitly handle all permutations, or find a way to reorder messages
where applicable. This is essentially what the selective receive does in
this example.

In the case of allocating a resource, strictly speaking, we shouldn't
allocate the resource if the subscriber has already put the phone down.
But since we have to handle the case that the on_hook signal arrived
*after* we allocated the connection, and the two entities (resource
handler and subscriber) are unsynchronized, we may reorder the events to
fit our logic. This radically reduces the number of combinations we are
forced to write code for.

UML has an attribute, deferrable_event, which allows the designer to do
pretty much the same thing. My gripe with that approach is that the
consequences can be dire if one forgets to add the deferrable_event
attribute (the UML default is to discard unexpected messages.)

So far, I'm of the opinion that this phenomenon is restricted to transient
states. You never (?) need selective receive in top-level states. If this
is true, then one should be able to label states such that they either
leave unexpected messages in the queue, discard them, or raise an
exception. What the default should be probably depends on the domain.

In my presentation, I offered an example of an event-based program that
switched between a selective dispatch loop and a plain dispatch loop
depending on context. This also seems to solve the problem of complexity
explosion in the code.

> If the intent is to delay any messages until we get out of
> the waiting state, then the following would work (but would
> be inefficient, as discussed in the  earlier thread at  
> <http://www.erlang.org/ml-archive/erlang-questions/200507/msg00301.html>):
>          bind waiting {
>               match [verb, args] { E.send(pots, verb, args) }
>           }
> Hmm, maybe selective receive would be beneficial here.

The efficiency part is in practice (at least in the telco domain) very
seldomly a problem, but of course could be under special circumstances.

OTOH, I've seen several examples of how programmers have defered the
ordering problem to user-level, effecively re-implementing selective
receive there. This doesn't make it more efficient.

Ulf W
Ulf Wiger

More information about the e-lang mailing list