Re^4: Using functional programming to reduce the pain of parallel-execution programming (with threads, forks, or name your poison)

[tphyahoo]

in reply to Re^3: Using functional programming to reduce the pain of parallel-execution programming (with threads, forks, or name your poison)
in thread Using functional programming to reduce the pain of parallel-execution programming (with threads, forks, or name your poison)

>> Therefore if you really don't want to convert function 
>> calls then I'd use something like Parallel::ForkManager
>> and build my own solution.

I did this at Using DBM::Deep and Parallel::ForkManager for a generalized parallel hashmap function builder (followup to "reducing pain of parallelization with FP")

The difficulty was getting my mapped result set back into a hashref that I could return at the end of the function, after all my child processes finished. I wound up "re agglomerating" my hash by storing the results of each function call on the hard drive with DBM::Deep.

I wound up needing to use a separate DBM::Deep file for each element of the hash, as I was unable to do this with a single DBM::Deep file, although I attempted to take advantage of locking support.

I wonder if there are other ways, including perhaps your previous suggestion to use ipc open3, perhaps bypassing having to store stuff on the hard drive completely. to be continued...