Starting v3

[kirkshoop]

My thoughts on starting v3.

• decide whether to create a separate branch or a v3 dir in the master branch.
• discuss the prototype and decide if it should be used as the starting point.
• discuss dependencies C++14, C++17, other libraries, etc..
• get the v3 build/CI/docs/tests working
• port sources and operators!

[marknevarrik]

If I may ask because I don't see a roadmap, what is v3 trying to address that couldn't be submitted to v2? Does it want to move to be easier to use? To be more C++ idiomatic vs. Rx idiomatic? What are the current pain points?

[kirkshoop]

I built the v3 prototype to demonstrate building Rx operators using c++14 auto lambdas in slides. v2 is C++11 only and compiles all the way back to vs2013.

expression structure

Along the way I re-evaluated the structure of an Rx expression. The v3 structure has some desirable properties.

1. allows operators to be composed before they are bound to a value type, error type or a source or a destination.

auto reportandignore = switch_on_error([](auto e){log(e); return empty();}) | repeat();

This defines reportandignore as a new operator that can be used in many expressions.

interval(1s) 
  | merge_transform([](long){ 
      return http.get("http://localhost") 
        | transform([](response r){return r.body(); }); 
    })
  | reportandignore
  . . .

2. allows a source to produce multiple value types.

struct cstr_or_string {
    void operator()(const char* cstr) const {cout << "cstr   - " << cstr << endl;}
    void operator()(const string& s) const {cout <<  "string - " << s << endl;}
};

cstr_or_string can be used with a source that calls next with different types.

create([](auto out){out.next("1"); out.next(string{"2"}; out.complete();)})
  | tap(cstr_or_string{})
  . . .

async lifetime

operators that have state, heap allocate into shared_ptr (to support async lifetime which does not fit in a C++ block) - this compounds as operators are composed together. I wanted to explore an async_ptr whose lifetime was controlled by an async scope, not a separate ref count per operator.

I think the current implementation in v3 needs review and probably a rewrite.

scheduling

The goal of scheduling is to allow many different concurrency abstractions to be adapted to the algorithms. std::thread a platform thread pool, a actor library, a gui event loop or any other way to schedule a function to happen at a particular time.

the algorithms also use scheduling to opt into thread-safety. Rx .Net ended up building each algorithm with lock-free code. this is error prone and pessimizes performance. in v2 and v3 operators that need thread-safety take a scheduler that defaults to a noop that adds no overhead to the cases where operators are dealing with events from the same thread (often the case when handling gui events like clicks and presses)

I wanted to get rid of the coordination (that I built in v2 to accomplish this) because I now believe that I can just use scheduler to extract thread-safety from each operator.

I think the current implementation in v3 needs review and probably a rewrite.

contribute

I am sure that there are more issues and improvements and shift in the goals that need to happen to get v3 into shape. Please open individual issues to discuss specific topics.

Thanks!

[leira]

How is this task going now? The latest change I saw in https://github.com/kirkshoop/rxcppv3 was from Sep 22, 2016. What is the plan? To have a new implementation with https://github.com/kirkshoop/rxcppv3, or have some incremental change here?