> Have you measured the overhead? What is it's like? Sort of, but not with the RPC setup. It doesn't seem too bad with the asynchttp, but it'd need proper http load tester instead of just curl.
> I'm quite sure it can be done, other purely refcounted systems have async too > (Rust, C++, Swift). But how the callback types are setup needs to be > redesigned then. That was so much work for us than we gave up and added a > cycle collector to ARC. I That makes complete sense. It looks like it'd be a lot of work to redesign. Rust wasn't able to use async in embedded (with `![no_std]`) for a long time [either](https://ferrous-systems.com/blog/embedded-async-await/). Though more because they didn't have their standard library. > I hope with strategic acyclic and cursor annotations the overhead of the > cycle collector can be pushed to the "noise" level. That'd be excellent, and seems plausible. From basic testing, the cycle collector overhead doesn't seem too bad, but for my embedded use cases I'm worried about any pause occurring at the wrong time. For the high speed [ADC](https://forum.nim-lang.org/postActivity.xml) devices I use even a few uS is enough to drop readings since DMA doesn't work with them. Using ARC it's pretty easy to reason about delay times... though as writing this I'm rethinking the ORC pause times. My tight ADC loops will avoid any heap allocation/dealloc's anyway, so if ORC only runs on a decrement then I'd be good! It's correct that the ORC cycle collector will only run at/on GC ref/decr's? Currently I'm writing my code to use the FreeRTOS xQueue primitives for sharing data between cores and keeping my RPC calls purely synchronous which fits my use case but it'd be fun to have a full async RPC system. **_Also_** , it's good to note that ARC works perfectly on the ESP32 multi-core heap! I had to do a `GC_ref` to keep ARC from deleting the data after passing it on the FreeRTOS data queue. @Yardanico / @juancarlospaco \-- I'll try some of those flags
