Currently, if the lambda provided instead of the queue/array/enumerable it's executed in one of the threads.
As far as I can see, the only reason to provide the producing lambda separately from the processing block is to separate the producer to run in the main thread.
Example (from real life, but simplified):
suppose user.generate_update takes 0.1s and MUST happen in the main thread due to DB connections limit
But send_update_api(params) takes 1s and so I want to parallelize the net calls in this case, so my idea for the code would be:
Parallel.each( -> { user = users.shift; user&.generate_update || Parallel::Stop }, in_threads: 10) do |params|
send_update_api(params)
end
But the generate_update also runs in the threads and so I need to use another implementation, such as FixedThreadPool, or write my own solution.
Currently, if the lambda provided instead of the queue/array/enumerable it's executed in one of the threads.
As far as I can see, the only reason to provide the producing lambda separately from the processing block is to separate the producer to run in the main thread.
Example (from real life, but simplified):
suppose
user.generate_updatetakes 0.1s and MUST happen in the main thread due to DB connections limitBut
send_update_api(params)takes 1s and so I want to parallelize the net calls in this case, so my idea for the code would be:But the
generate_updatealso runs in the threads and so I need to use another implementation, such as FixedThreadPool, or write my own solution.