[erlang-questions] value of spawned function

[Ulf Wiger]

2008/9/21 Zvi <exta7@REDACTED>:
>
> But my rant was about impurity/assymetry of Erlang API, i.e.:
> 1. erlang:spawn, without erlang:join
> 2. Erlang is multiparadigm language, so Actors implemented using functions,
> so even if functions return values, actors/processes does not. So to return
> value we need a wrapper fun and a sending a message.

What you're seeing is the consequence of the view that processes are
spawned by a supervisor, which normally doesn't care about the result
of the child's computation - only if it completes as planned or if it may
need to be restarted.

Either way you look at it, you will have some inconvenient case if
a process terminates by simply not recursing any more. If it happens
to end on an expression that returns a huge term, the EXIT message
will be huge as well. If the spawning process only cared about whether
it died normally, this will have amounted to an expensive and unnecessary
copy, and the recommendation would have to be to always exit explicitly
with a small return value, unless the spawner really needs to know the
result.

In most applications written in Erlang so far, I believe this to be the
most common pattern, and the implicit exit(normal) is logical and
convenient.


> For me Actors/message passing is a assembler of concurrent programming.
> There is a need for standard framework for higher level models:
> * Task-level parallel:  Fork-Join,  Manager-Workers (aka Master-Slave - pool
> and slave modules?)
> * Data-parallel:  parallel list comprehensions,  plists module, Map/Reduce

That discussion has indeed started now, and SMP Erlang is the enabler.
As long as Erlang always used only one scheduler, there wasn't much
point in having such a framework.


> But your solution still have some problems, like quickly reaching process
> limit for real life tasks and crushing BEAM. So instead of spawning Erlang
> process for each subtask, I need to implement scheduler processes per core.
> I trying to implement general Fork-Join framework, like this one:
>
> Result solve(Problem problem) {
>          if (problem is small)
>               directly solve problem
>          else {
>              split problem into independent parts
>              fork new subtasks to solve each part
>              join all subtasks
>             compose result from subresults
>         }
> }

...and of course, determining the 'problem is small' condition is very
difficult in general. Most languages that specialize in parallel computation
will have finer-grained processes than Erlang, making this particular test
unnecessary.

BR,
Ulf W