[erlang-questions] Ideas for a new Erlang
Tue Aug 5 16:35:29 CEST 2008
Ulf Wiger skrev:
> 2008/8/1 Sven-Olof Nystr|m <svenolof@REDACTED>:
>> Ulf Wiger writes:
>> > > Ulf Wiger writes:
>> 2) One of the problem you are discussing is how to describe
>> concurrent activities within one state machine. UML's mechanism
>> for expressing composite state seems to be close to what is
>> needed here.
> Not as far as I understand them. The composite state machines allow
> you to build very complex receive logic, but the message reception
> semantics is still FIFO, run-to-completion.
> There is, however, an attribute in UML - 'deferrable event', which allows
> you to specify that an event should be buffered, rather than discarded,
> if there is no matching handler in the current state. Not all UML-based
> tools support this attribute, and it receives very little attention in the
> The key issue is that if you collect messages from different senders in
> a single mailbox or message queue, there will be accidental ordering.
> If your program logic strictly handles messages FIFO, it imposes a
> requirement that you have to be able to deal with all possible
> serializations of events - which invariably means that you have to
> perform some form of buffering in your application.
> Buffering channels address this problem, of course.
> The reason why I suggested that you look at the POTS example
> wasn't that I didn't think you could solve it with channels; it was
> to give you an *interesting* example in order to assess whether
> a channel-based solution would be more or less elegant than the
> traditional erlang version.
RoseRT has defer/recall(All) and you can make recall on a port or all.
You can choose if you recall from the front. We have a very complex
state machine in this technology and it would be very interesting to see
how it could be simplified in alternative technology which would be a
very good thesis project.
More information about the erlang-questions