[erlang-questions] Ideas for a new Erlang

[Ulf Wiger]

2008/7/24 Sven-Olof Nystr|m <svenolof@REDACTED>:
> Ulf Wiger writes:
>  >
>  > You should also take a look at the presentation that I referred to.
>  >
>  > Just looking at the example in the book, you are making the same
>  > mistake as the Nordlander thesis on OHaskell. The POTS system
>  > also uses messages to control the switch hardware, and this control
>  > is stateful and synchronous. Furthermore, I believe that the MD110
>  > hardware had no way to queue requests, so the control system must
>  > take care to issue only one request at a time.
>  >
>  > The OHaskell example assumed that functions like start_tone()
>  > were atomic and non-blocking - they are not.
>
> OK, I actually wrote a simple framework to be able to run the
> code. The framework used a process to simulate the hardware and
> naturally there were some receive expressions, for example in
> analyse(). But the function start_tone and other similar functions
> were not blocking. I saw those as being outside the POTS example, so I
> did not comment on them. (The communications followed the simple
> pattern I discussed in the example with the counter program.)
>
>  > In my presentation, I also made the number analysis asynchronous,
>  > which may seem far-fetched in the limited POTS example, but is quite
>  > realistic when one considers modern IP-based telephone. The
>  > idea was to convert synchronous requests into explicit asynchronous
>  > request-reply pairs, and having at least two such protocols that could
>  > interleave.
>
> I noted a slide with the comment "simple main event loop with fifo
> semantics". Seems to be similar to what I am trying to do.
>
> You bring up some interesting issues in your presentation but the code
> you show don't seem to make much use of selective receive.

Not much, but the vital use of selective receive is in the start_tone()
and similar functions. The key part is that the function blocks and
waits for a specific response to its particular signal, and doesn't
return to the surrounding control loop until it knows whether or
not the operation succeeded. Since selective receive makes this
possible, the top-level control loop is free to assume that start_tone()
is atomic. This particular assumption is illegal in OHaskell, for example.

> I am not sure what you mean by synchronous and unsynchronous. In
> an Erlang context, I thought synchronous meant a communication
> implemented as a send-request pair, but you seem to be making a
> distinction here. Also, aren't all Erlang programs event-based
> (event=message)?

No, that's the interpretation of synchronous that I meant.
Many programming frameworks do not allow operations
like start_tone() to block, which means that such operations
must be carried out as explicit request-reply pairs, which
become visible in the global state-event matrix.

The last example in the presentation implements a filtering
event loop, which might be similar to a solution using
channels.

>  > A SIP signaling control system can make as much as 5-10 network-
>  > based (or more) requests for one call, for things like billing,
>  > admission control, location lookup, resource allocation, etc.
>  > All conceptually synchronous,  but the SIP signaling is asynchronous.
>  > The interleaving of all signals make a global state-event matrix
>  > impossibly complicated, so conceptual layering is essential.
>
> This is interesting stuff. I suppose one can't simply split one side
> of a communication into several processes?

Sure, but that doesn't solve the problem.

Take the case of admission control. It is triggered by the main
call control state machine, and the continuation depends on
the result of the request. It's prudent to let a separate process
deal with the DIAMETER specifics (which may involve failure
detection and retransmission/rerouting of the request), but
the main state machine must still await the result. If it
sends the request and doesn't selectively wait for the reply,
other signals may arrive that conflict with the outstanding
request. If I implement a wrapper around the DIAMETER
request-response pair used for admission control, it doesn't
affect the state machine any more than if it were an atomic
check of a locally stored value.

BR,
Ulf W