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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk