pminten (16) [Avatar] Offline
#1
In chapter 9 you write "However, you should try to run the same computation from within the single
process.".

I'm somewhat torn over the terminology. It makes sense in the context of chapter 9, but I had to reread the surrounding text to be sure what was meant here. To me, intuitively, "same computation" refers to the same calculation, even if it has different inputs.

Perhaps it would be clearer to explicitly talk about computing a cached value. So you should try always compute a cached value from the same process.

As an aside: that really goes somewhat deeper than just caching. It ties into a more general principle, each value or resource should have at most one process authorative for it at a given time.

What this means for Erlang/Elixir is that when you have a value that can conceptually change over time, for example the PID of the database connection process, only a single process should get to "change" it. Other processes may request a copy of the current value and use it as a cached value but only the authorative process is allowed to decide that a different value will be the official one. If another process wants to have the most up-to-date value it will always have to ask the authorative process or look at some cache ((D)ETS/mnesia) that the authorative process has updated.

This way of thinking has some benefits when you get stuff like parallel transformation of data. A process splits up some data that it has authority over and passes the authority for those pieces of data to worker processes. When the workers are done they pass back the results and the authority for those. While the workers are busy the original process should be mindful that it is no longer authorative (even though for its clients it may look that way) and that it shouldn't go changing the data since otherwise things will become difficult when the results from the worker processes come in.

Ahem, but that as an aside.
sjuric (86) [Avatar] Offline
#2
Re: Running the same computation in the single process
Good point! I'll consider using cached value, or something similar.