[erlang-questions] lists:pmap ?
Thu Sep 7 00:44:29 CEST 2017
There are many issues you need to address if you are going to add a
"standard" pmap to your library. Some have already been mentioned like how
much parallelism and are you going to preserve the list order, which I
think is critical.
Another one is what to do when you get an error. There are some obvious
- If you get an error crash all the processes and return an error pretty
much in the same way map does
- Always return the full list but indicate which elements worked and which
didn't, or maybe just return a default "error" value
But you could always do something for your specific case.
On 30 August 2017 at 13:31, Ulf Wiger <> wrote:
> I discussed the problems with a general pmap in a presentation back in
> The purpose wasn't really to argue against a general pmap, but rather to
> use it as a simple example to illustrate the problems with treating erlang
> processes as 'fibers' rather than independent actors.
> Ulf W
> 2017-08-22 10:42 GMT+02:00 Ola Andersson A <>:
>> Reading the discussion about list:mapfind reminded me of a function I
>> rediscovered recently.
>> It's rpc:pmap/3 that was originally defined for use in a distributed
>> environment, spreading out the processing over several nodes. It actually
>> works on a single multicore node as well even though it wasn't designed for
>> that purpose.
>> With the limited tests I have done it seems to significantly outperform
>> lists:map/2 and also scale reasonably well. The almost negligible cost of
>> spawning erlang processes is still amazing.
>> How about adding a lists:pmap/2 function, designed for multicore, in the
>> lists module?
>> erlang-questions mailing list
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions