[erlang-questions] shared data areas (was Re: [erlang-questions] OOP in Erlang)

[Nicholas Frechette]

Perhaps erlang would benefit from a system similar to C# appdomains:
Functions calls intra appdomain are simple calls, function calls extra
appdomain are rpc calls where everything is copied. Obviously, this would
translate to message passing for erlang and not necessarily function calls.
Perhaps this could be implicit (ie: 1 domain per erlang application) or
perhaps explicit (ie: as groups using spawn_opt as you suggested). Maybe it
would make sense to create an EPP for a feature like the one you are
requesting Ulf, since as you've shown, there are cases where the simplest
design for a class of applications would benefit greatly from it (and thus
prevent complicating the design to work around performance bottlenecks).

Nicholas

On Tue, Aug 17, 2010 at 9:35 AM, Ulf Wiger
<ulf.wiger@REDACTED>wrote:

> Michael Turner wrote:
>
>> "... in my experience, from complex telephony and multimedia apps, it is
>> in fact pretty common to have thousands of small 'clusters' of state
>> machines, each cluster sharing a whopping big state record and taking turns
>> processing different parts of the control flow."
>>
>>
>> But what's behind the decision to structure things that way?
>>
>
> The fact that the signaling carries all information as a single
> session, but when you break it apart, there are lots of different
> state machines in there. You split them into different processes
> in order to avoid interference between state machines. Still,
> the signaling protocol forces them all to pack the data into
> a single state.
>
> Your proposed alternative seems quite complicated compared to
> the (optimization) option of letting the FSMs share a common heap,
> but that is from a *very* cursory perusal. I will try to read it
> more closely later.
>
>
> BR,
> Ulf W
> --
> Ulf Wiger
> CTO, Erlang Solutions Ltd, formerly Erlang Training & Consulting Ltd
> http://www.erlang-solutions.com
>