Subject: Re: [boost] RFC - Updated MapReduce library
From: Craig Henderson (cdm.henderson_at_[hidden])
Date: 2009-08-09 07:26:34
> 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
> 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
> 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
> ... 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
> to do in a parallel way and demonstrate that the MapReduce approach
> a value at some point (paraphrasing Murray Cole statement of "show the
Yes, I'll add that too.