Right, when I said "actually concurrent", I meant the code -could- run simultaneously (or more formally, that the items of execution aren't necessarily causally

Right, when I said "actually concurrent", I meant the code -could- run simultaneously (or more formally, that the items of execution aren't necessarily causally related). Any sequential operation could be spread out over an arbitrary number of Erlang processes, without it actually being concurrent. That design isn't concurrent, you just are involving a bunch of processes that wait. That said, you are right that a synch point around a controlled resource (i.e., "we only want to support processing 5 requests at a time") would still have concurrent tasks (i.e., ten requests come in; there is no casual relation between when they run). Of course...that's an intentional point of synchronization necessary for correctness; it still strikes me as a strawman to say that you don't get parallelization for concurrent code, just because you forced a bottleneck somewhere.