Joel wrote:
Why not having each thread with a local copy of the functor. Ideally, those are stateless anyway and thus this copy is mainly free. Other thing is, why not allowing the use of anything that acts as a function and provides the correct interface. You'll face the dreaded legacy code reuse wall if your users can't take their years old sequential function and turn it into a mapper or reducer. Storing boost::function inside the implementation to leverage this genericity is maybe a good idea.
This is how it started :) I'm happy to change it back again if consensus is that it is a cleaner interface. But doesn't it enable/encourage misuse of the separation of map tasks?
I like when my phone phones and my toaster toasts. When I want a phone that toast, I like to be able to explicitly decide so ;) Make it a policy is def. better in my book.
I agree that designation of tasks is better - I saw this as collecting metrics more that a distinct activity. I'll add "metric_policy" to the to-do list
It's mainly around the need to have type::other_type::stuff and to have to check/rememebr which comes before. An unified thing like result_of<type(user type)>::type looks better.
Sorry, but I'm not really understanding your point. Where in the user code is your objection? Can you cite an example and provide your preferred alternative?
... this is something I can contribute.
Thanks ! It should be easy to implement an openMP schedule_policy within the current framework.
Nice thing could be small scale examples tied to tasks that one can have to do in a parallel way and demonstrate that the MapReduce approach adds a value at some point (paraphrasing Murray Cole statement of "show the payback").
Yes, I'll add that too. Thanks -- Craig