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

[Ulf Wiger]

Den 2006-06-09 06:35:37 skrev David Hopwood  
<david.nospam.hopwood@REDACTED>:

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

Regards,
Ulf W
-- 
Ulf Wiger