[erlang-questions] How to Name Concurrency Patterns

[Richard A. O'Keefe]

On 20/02/2014, at 8:58 PM, Ulf Wiger wrote:

> Perhaps it should be called "concurrency-oriented patterns" instead? Strictly speaking, a pipe isn't about concurrency so much as serialization/chaining (and can be executed without any concurrency at all),

Well, UNIX pipelines are a good way to introduce the issues of
 - unbounded buffer -vs- bounded buffer
 - multiple reads and/or multiple writers
   (two or more concurrent processes can write to the same pipe,
   chunks smaller than PIPE_BUF -- somewhat misleadingly named --
   are atomic, bigger chunks maybe interleaved)
   (two or more concurrent processes can read from a pipe;
   presumably PIPE_BUF also applies to reading although I've
   never seen this stated)
 - flow control
 - why popen(cmd, mode) allows mode = "r" and "w" but not "r+" or "w+"

> A pattern I don't see mentioned often is what I might call 'orchestrator', where one process is assigned the responsibility for the overall 'script', dispatches tasks to workers and collects the results.

Turns out that's a sequential OOP pattern:
http://codereview.stackexchange.com/questions/25435/sequential-execution-orchestrator-pattern

Where do you draw the line (or indeed, is there any point in
drawing a line) between this and Master/Worker?

> I would say that pmap() is a simple orchestrator pattern, and a good opportunity to explain both supervision and selective receive.

pmap is a simple master/worker case where all the workers are
doing the same kind of job.