Keynote: Employing Senders & Receivers to Tame Concurrency in C++ Embedded Systems - Michael Caisse

[@KrzysiekPierczyk-uq1du]

How is it that every time I tell my colleagues (working as an embedded C++ dev) "Hey guys, we have this repeatedly occurring design problem in our applications. You know what? I will write this super cool, heavily templated library that will get the job done in a unified way with a nice declarative syntax" there is this talk later *the same year* given by someone from Intel's embedded team where the prelegent says "You know what? We had this repe... So we've written the library. Here it is. Pick it" :| That was the case with cib, message library and now with groov. I absolutely love seeing such an approach in my beloved domain that is still swimming in the sea of 90's C-style souls!

[@aniketbisht2823]

I remember watching a seminal talk by Michael Caisse about Boost.ASIO when I was getting started with C++ and programming in general. This talk has the same charm. Thank you.

[@MichaelCaisse]

Thank you for the kinds words! I'm very excited about this design pattern. Look for a new conference talk on using senders before the year is out.

[@KrzysiekPierczyk-uq1du]

I can confirm - the same story, the same feeling :D

[@tommybandzaw5865]

Great talk! Thanks Michael!

[@MichaelCaisse]

Thank you! I hope you found some useful concepts in the talk.

[@mjKlaim]

Excellent presentation 👍🏽 Note that personally I would have said that "sender factories" are the event generators, not only schedulers (which are also sender factories)

[@joeedh]

Oh and the original video linked at 37:00 crashes KZbin. Are all talks on async graphs just trolling?

[@aniketbisht2823]

Great talk.

[@simonfarre4907]

Wait I had totally expected senders and receivers to be, exactly what senders and receivers are in every other language (channels). Why has C++ decided to take a concept and name it the exact same as some other, well established in other languages feature? That sounds like crazy land to me. Also, why are senders and receivers looking like futures and promises in combination with coroutines in this talk - and more importantly - why are we needing *another* one of those systems? These senders and receivers also look _identical_ to kotlins coroutines (or Rust's coroutines/async). Why has C++ decided to muddy the waters this bad when we have multiple large userbase languages with these features but they aren't called senders and receivers. From what I can tell, *many* languages has senders and receivers yet *none* of them look like coroutines like this. Am I wrong about this?

[@chaquator]

c++ moment

[@mischan]

Thanks for this excellent presentation. I don't know if enough people in embedded systems appreciate this paradigm's value, independent of language or implementation, so any visualization of its application in the field is a service to the community. Any firmware developer will be exposed to the design/architecture forces between schedule efficiency, modularity of components to be scheduled (down to the lowest level drivers), and reasoning of concurrent behavior. Every project I worked on was affected by exactly the issues Michael mentioned in the presentation, even if we considered them early on. If an RTOS is off the table (for whatever reason), it looks like this approach solves a huge part of the design space for systems that manage a lot of async behavior without dropping a lot of control. I hope the quality of code generation and compile times will scale with the problems thrown at it. Another question is how well one can reason about the global schedule timing across all execution contexts, given that with "senders", they are composed of locally specified use cases.

[@PerriPaprikash]

How is someone supposed to debug code written in terms of SnR? the standard version of the logging example is way more readable and comprehendible that the SnR version.

[@xealit]

Nice talk, but flaky. It doesn’t really reveal some insight into senders. Butter to watch after something else.

[@joeedh]

I can't believe I watched for 40 minutes to not get an introduction to senders.

[@joeedh]

So annoying