stdexec VS libunifex

I searched for more information, and here are some relevant links, in case anybody else is interested: * https://www.reddit.com/r/cpp/comments/zdogz9/new_c_sender_library_enables_portable_asynchrony/ * https://github.com/nvidia/stdexec * https://www.reddit.com/r/cpp/comments/10b76e3/stdexecution_from_the_metal_up_paul_bendixen/ * https://www.reddit.com/r/cpp/comments/st9bjm/p2300_senderreceiver_is_dead_in_the_water_for_c23/

The last direct news about the status of P2547R1 that I'm aware of was with the Soursop and Ponies in Kona blogpost in November 22. r/cpp looks to not have discussed CPOs directly when the post was linked. Indirectly, this Github issue hints that there is a strong possibility of no language alternative available by C++26.

Coroutine task types and other awaitables are well supported by the P2300 std::execution proposal. Take a look at https://github.com/NVIDIA/stdexec Coroutines in general are good at suspension and resumption, but they need a place to run and something to resume them. That's what the sender/receiver framework provides.

Looking for a Study Partner (for SERIOUS learning), in the fields of Robotics | Accelerated Computing.I am studying Electrical Engineering (5 out of 7 semesters) and live in Germany. But yeah, College sucks and I mostly use online resources like NVIDIA's DLI, Coursera, edX, Educative and O'Reilly. [I really don't understand how these aren't the new Universities/Colleges. All I know I learned either from there or Youtube, Udemy or Books. College is actually what is slowing me down. It's such a waste of my time and resources. I asked ONE thing from them, and still, that was too much. They didn't do it.Anyway...I am currently going through/finally sorting out some Data Structures and Algorithms stuff (specially Graphs) and my plans/next goals are 1 - Go through C++'s P2300 Proposal and try to understand it along with NVIDIA's stdexec implementation, 2 - Take NVIDIA's CUDA C++ Course, 3 - Get started with Computer Vision [probably using NVIDIA again haha, along with OpenCV)

Libunifex inspired P2300, but the design of P2300 has evolved since then and libunifex has not kept pace. stdexec is a faithful and up-to-date implementation of P2300. It also adds GPU support and a small number of schedulers and utilities not in P2300.

It is on Github, btw: https://github.com/brycelelbach/wg21_p2300_std_execution

I can't really argue that composing algorithms either using function call or pipe syntax is more readable than coroutines. I'll say this: right now P2300 is missing some discussion of how senders can be made trivially awaitable in a coroutine (and awaitables are senders by definition). If coroutines are your preferred syntax, sender/receiver is still a sound basis. Those parts of P2300 are currently under code review. You can find the PRs here.

I'm curious what led you to this conclusion. If you ran into scalability issues with its static_thread_pool, then that's a known issue. If it's something else, the authors (of which I'm one) would love to know.

Instead of calling add_executable you will call add_library. Here is a (only moderately complicated) production example of a library that can be built standalone (along with tests and example executables), or as a subproject, where it builds only the library

My original thought was to build my DDS implementation on top of libunifex in anticipation for standardization: https://github.com/facebookexperimental/libunifex

I'm trying to understand how to work with the proposed executors in a project, but after watching Eric Niebler's cppcon talks (https://youtu.be/xLboNIf7BTg) and looking at the libunifex examples (https://github.com/facebookexperimental/libunifex/tree/main/examples) I still have a hard time wrapping my head around how to employ the sender/receiver pattern in a larger project.

You have coroutines in C++20 but there is also the executives proposal that's making it's way into C++23 that is available as a library under the name unifex that only requires C++14

Asio-grpc makes exactly that possible by providing an Asio execution_context compatible interface to the CompletionQueue. It supports all types of RPCs (including generic ones), completion tokens, cancellation, as well as libunifex sender/receiver (if you want to try out what might become std::execution). The latest release (v1.7.0) also introduced a GrpcStream class for writing Rust/Golang select-style code.

P2300: they are trying to standardize facebookexperimental/libunifex

All the network handling for Instagram and all other Meta apps on all platforms is handled by their own C++ library https://github.com/facebookexperimental/libunifex.

This. I'd also like to mention libunifex. It's entirely based on tag_invoke and is a testament as to how much power it actually provides. On the other hand, it also proves how cumbersome it is to define CPOs with tag_invoke. But IMO it's a lot better than anything else anyone has ever created, and users usually don't need to define new CPOs, only library writers do, so there's that.

A work in progress implementation of the library: https://github.com/facebookexperimental/libunifex