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

[tilly]

Yes, that only works with command line programs.

But it is pretty easy to convert function calls to command line programs.

In any case, I wouldn't use Parallel::Simple because I have always valued the ability to control how many children I have at once. (Generally there is a fairly fixed amount of potential parallelism. Using that many kids get gets maximum throughput. If you go higher or lower your overall throughput goes down.) Therefore if you really don't want to convert function calls then I'd use something like Parallel::ForkManager and build my own solution.

[tphyahoo]

>> 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...