Re: [boost] RFC - Updated MapReduce library

Subject: Re: [boost] RFC - Updated MapReduce library
From: Craig Henderson (cdm.henderson_at_[hidden])
Date: 2009-08-09 07:26:34

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