Re: [boost] [GSoC] pipelines questions

Subject: Re: [boost] [GSoC] pipelines questions
From: Thaler Benedek (thalerbenedek_at_[hidden])
Date: 2014-03-01 10:32:42

Hi,

Then n3534 shows the following example: [0]

pipeline::execution task(
  pipeline::from(filenames) |
  pipeline::parallel(read_file | grep_fn | vgrep_fn | sed_fn, 8) |
  output_queue).run(&thread_pool);

I can't figure out how to create a segment from "read_file | grep_fn |
vgrep_fn | sed_fn" without overloading the free function
operator|(function, function). Is this really we want to do? Shouldn't we
use pipeline::make() here?

Thanks,
Benedek

[0]:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3534.html#Parallel

On Tue, Feb 25, 2014 at 12:01 AM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 24/02/14 21:58, Thaler Benedek a écrit :
>
>> Hi,
>>
> Hi,
>
>> I'm interested in the Boost.Pipelines proposal of GSoC 2014. [0] I'd like
>> to ask the stakeholder (Vicente J. Botet Escriba ?) the following:
>>
>> * Is this supposed to be built from scratch or rather to be some kind of
>> improvement over the already existing google implementation? [1]
>>
> from scratch using whatever C++11 library (or Boost). The Google
> implementation is just one implementation that can be inspected.
>
>  * If the former is true, should be n3534 [2] considered as a strict
>> requirement or as a vague suggestion?
>>
> I'm open to any design that improves the proposal.
>
>
>> * If the later is true, which features should be the main distinctive
>> ones?
>> I think about things like using Boost libraries (e.g: Boost.Atomic)
>> instead
>> of custom solutions, cross platform support, comply to Boost coding
>> standard, etc. Are there any areas of improvement identified in the
>> reference implementation?
>>
> I have not inspected too much the Google implementation :(
>
> I would prefer to have an implementation that takes advantage of any C++11
> feature that make the user interface more friendly. Only once we have this
> implementation we would move to a portable implementation to C++98
> compilers using Boost.
>
>
>> * I understand it might take quite a long time for a proposal to make it
>> to
>> Boost, therefore it's not a requirement. Is there any objective milestone
>> that a successful project should reach anyway?
>>
> I would prefer that the project delivers something that can be included
> into boost at each step. That is the project would be iterative and so
> there would be something useful at the end.
> Boost.thread contains already most of the building blocks (thread safe
> queue and executors), so I don't think that the project will take too long.
> The time given by GSoC should be enough.
>
>
> Best,
> Vicente
>
>
>> Thanks,
>> Benedek
>>
>> [0]: https://svn.boost.org/trac/boost/wiki/SoC2014#Boost.Pipelines
>> [1]:
>> https://code.google.com/p/google-concurrency-library/
>> source/browse/include/pipeline.h
>> [2]:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/
>> n3534.html#Proposal
>>
>> _______________________________________________
>> Unsubscribe & other changes: http://lists.boost.org/
>> mailman/listinfo.cgi/boost
>>
>>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/
> mailman/listinfo.cgi/boost
>