why concurrency in the first place?
Thu Feb 8 09:15:40 CET 2001
On Wed, 7 Feb 2001, Vlad Dumitrescu wrote:
>I find this discussion very interesting.
>But right now I'd like to ask something about something Ulf said:
>From: "Ulf Wiger" <>
>> Looking into, say, the A side half-call, you will find several
>> independent state machines. They are not concurrent in one sense, as
>> their state transitions are tightly coupled, but you can, for example
>> replace one (protocol) layer 3 FSM with another. As it turns out,
>> implementing these FSMs as separate processes in Erlang would be a
>Why would it be a mistake? (I can think of some reasons, but I'd
>like to hear yours... :-)
>Is it the tight coupling? Efficiency? A design 'no-no'?
A couple of reasons:
- error handling becomes slightly less straightforward
- efficiency suffers because of extra message passing
- latency is increased due to scheduling delays
Ulf Wiger tfn: +46 8 719 81 95
Senior System Architect mob: +46 70 519 81 95
Strategic Product & System Management ATM Multiservice Networks
Data Backbone & Optical Services Division Ericsson Telecom AB
More information about the erlang-questions