Make rpp ready for embedded systems?

[daixtrose]

First, I am super excited about the existence of rpp. I am very happy that someone tackled the issues of RxCpp and that reactive extensions for C++ took the next evolution step. @victimsnino many, many thanks for making this happen!

I'd like to discuss, whether it would be possible to have the code be a bit more platform-agnostic. I see many use cases for embedded systems, and the Emscripten/WASM community might be grateful, too, if the "normal" OS primitives for thread safety would only kick in as a customization point.

std::unique_lock lock{m_mutex}; is not available on some platforms. Since some operators like debounce rely on an available mutex the library loses some "customers" who are waiting eagerly for this library.

The direct use of std::lock_guard on mutex makes me feel uncomfortable. This does not mean that the code is not correct. I always fear a deadlock popping up somewhere. I always find it hard to reason whether I got it right. CopperSpice's libguarded to my rescue in most cases.

For a modern C++ library using MACROs is ugly but at least a straightforward mitigation for having this library run on top of e.g. modm.

        template<typename TT>
        void emplace_safe(TT&& v)
        {
#ifndef NO_AUTOMATIC_THREAD_SAFETY // <============
            std::lock_guard lock{m_mutex};
#endif 
            m_value_to_be_emitted.emplace(std::forward<TT>(v));
            const bool need_to_scheduled        = !m_time_when_value_should_be_emitted.has_value();
            m_time_when_value_should_be_emitted = m_worker.now() + m_period;
            if (need_to_scheduled)
            {
                schedule();
            }
        }

I consider this not a direct customization point. Not sure how to allow other synchronization methods to be injected. How to use modm's fiber implementation or coroutines I have not thought through yet.

Any comments?

[victimsnino]

@daixtrose, thanks! =)

I think, it is really good topic to discuss. To be honest, I have zero experience in embedded systems so I can't provide any valuable comment related to this part, but if we just narrow down to question "is it possible to customize synchronization primitives?" - i think it is pretty possible to do.

First ever idea i can imagine from scratch right now:
move all such an things to single header and implement it for different platforms. Something like

// something like rpp/utils/synchronization.hpp

#ifdef RPP_EMBEDED
class mutex {
 // todo
};
#else
using mutex = std::mutex;
#endif

It is a bit clumsy and forces rpp to support all variants iself... but at least avoids direct issues inside source code

One more thing, is to use different specialization and etc. Something like this: https://gcc.godbolt.org/z/KaPrhvcxv

but in this case user have to provide specialization before first ever usage of anything from rpp, not sure if it would be possible/easy to use

[victimsnino]

Maybe extra one more thing is to add template argument to such an operators and provide ability user's to override such an params, but it would be really hard =C

[daixtrose]

Redactional comment: Adding the full link to Godbolt containing the code for future reference and readers who stumble upon this discussion in a decade.

[daixtrose]

Simply including a header with my own definitions first is the kind of customization that I would prefer. No MACROs required then.

#include <iostream>

#ifndef EMBEDDED

// content of a user-defined header with arbitrary file name
namespace rpp {
    struct mutex_impl
    {
        void lock() { std::cout << "CUSTOM LOCK MECHANISM" << std::endl;}
    };
} // namespace rpp

// EOF
#endif

#include <type_traits>

// This hack stolen is from Raymond Chen's article at 
// https://devblogs.microsoft.com/oldnewthing/20190710-00/?p=102678

template<typename, typename = void>
constexpr bool is_type_complete_v = false;

template<typename T>
constexpr bool is_type_complete_v
    <T, std::void_t<decltype(sizeof(T))>> = true;

namespace rpp {
    struct mutex_impl;

    struct default_mutex {
        void lock() { std::cout << "RPP LOCK" << std::endl;}
    };

    using mutex = 
        std::conditional_t<is_type_complete_v<mutex_impl>, rpp::mutex_impl, default_mutex>;  

    template<typename T>
    void debounce() {
        auto m = mutex();
        m.lock();
    }
}

int main() {
    rpp::debounce<int>();
}

[victimsnino]

Yeah, looks promising. Questions we need to solve:

1. does it solve original issue related to unique_lock can be not available on some platforms? I mean, it looks like we have to hide it under ifdef, isnt it? Dont we get compile error with message about unexisting class?
2. we can easily handle it via creation some custom custom_rpp.hpp, but in this case such an header should include whole rpp/rpp.hpp, isnt it? Currently you can just include any parts you want to use in your code instead of whole rpp. like #include <rpp/operators/map.hpp.

[andreamancuso]

+1 for emscripten support

This is what I've been working on, declarative React bindings for Dear Imgui (and eventually egui, written in Rust): https://andreamancuso.github.io/react-wasm/dear-imgui/ (very, very rough demo - Chrome, Edge, Firefox Nightly only)

I now need to add reactive programming into the mix in order to boost performance through async events/data exchange.

I've read about std::execution but I am new to C++, whereas I am fairly familiar with RxJS - I would totally prefer using your library!

[victimsnino]

Ok, looks like this one is enough
#598

[andreamancuso]

Out of interest, would this https://vcpkg.io/en/package/reactiveplusplus need to be updated too?

[victimsnino]

Yeah, it have to. vcpkg configured with specific version of rpp. I would submit PullRequest to vcpkg and conan for next release of RPP, but i can't give any ETA about it =)
As far as i understand concept of vcpkg, you can fork it and does local changes something like this:
https://github.com/microsoft/vcpkg/pull/39011/files

and use forked vcpkg. In my understanding it is common practice =)

[andreamancuso]

It's finally building!

diff --git a/ports/reactiveplusplus/portfile.cmake b/ports/reactiveplusplus/portfile.cmake
index 6b76b3d..e37e59f 100644
--- a/ports/reactiveplusplus/portfile.cmake
+++ b/ports/reactiveplusplus/portfile.cmake
@@ -1,8 +1,8 @@
 vcpkg_from_github(
     OUT_SOURCE_PATH SOURCE_PATH
     REPO victimsnino/ReactivePlusPlus
-    REF "v${VERSION}"
-    SHA512 b19a164bf19f787ca182f88a616317eea122b76fea9ab0b90b2fe05e30ab94a7540b33aef1156003141dd4b0bc30b41bf2dc224a8cbe31707ab111bcfd7a3c5b
+    REF 104bf4610d177f641ab92b37b9197d703e4ed2d0
+    SHA512 27ce93922a95effbd956018a971c6bc696044585f5fadffc28f536e22c483fd7273997a8dc8ef589667bffe61541468724b71ee9dcbcd763b3b2704fcb921652
     HEAD_REF master
 )

[andreamancuso]

That is the only way I was able to force vcpkg to use a specific commit of ReactivePlusPlus. Perhaps there's a proper way - but this appears to be working well so I'm happy. 👍