Started off on a ringbuffer-based ABI stable asyncread / asyncwrite pair because the only existing solution seems abandoned with open issues and not much activity.

Over the weekend I'll extract it into a crate and write a heap of tests. Async code is a bitch to test, but it's probably the least worst in Rust where the testing scaffold can manually step all of the async codepaths.

https://git.lbfalvy.com/Orchid/...

You've been busy. Clear inline comments btw. But still totallii not understandii Rustii.

@retoor I'm not sure what kind of projects @BlindXfish is expecting us to upload, and this is purely a vibes-based assertion, but it seems very visual with all the cards and stuff so I'm guessing that a non-thread-safe async binary-safe ringbuffer library for Rust probably doesn't fit very well.

to begin with, a non-thread-safe ringbuffer pretty much only makes sense if your architectural decisions are as weird as mine.

@retoor I extracted it and wrote a nice test scaffold with random sized reads and writes:

https://git.lbfalvy.com/Orchid/...

There's a deadlock in it somewhere but I cannot for the life of me figure out where, this has me wondering if there's a rule about futures that I didn't learn right that's causing all these weird deadlocks in Orchid as well.

This is pretty solid but not nearly sufficient testing, I want to try some weird scenarios with flushing and closing as well once this one passes, and probably a benchmark for the use-case of a sequence of many small writes of varying sizes followed by a sequence of matching sized reads, because this is how Orchid and I imagine most real-world binary protocols use their channels.

@retoor no deadlock I just messed up the test because I thought an i32 was 8 bytes. It works fine as best I can tell.

And that's a stepping stone laid.

https://crates.io/crates/...

I'm excited because this should pave the road towards testing some important and complex subcomponents, not even considering how it will enable dylib plugins.

I rewrote the request-notify duplex comm primitive on top of it, it works well, and testing is a bliss

Serverless application development has become a practical option for companies that want flexibility without managing complex infrastructure. By relying on cloud providers to handle scaling and maintenance, teams can focus on building features that support real business goals. This approach reduces operational overhead and allows faster updates when requirements change. Many companies explore options like https://velvetech.com/serverless-ap... to understand how serverless solutions can support stable performance, cost control, and faster product iteration in competitive markets.