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.

Don't forget to publish on devplace.net as wel that actually has a project showcase post type. Three projects are updated there today. I published rproxy, the engine behind dr.molodetz.nl and it's nice live dashboard. The statistics page is 6ms on average over 10.000 calls, 200+ req/s over 64 vhosts while already under load. 20mb/s.

@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