Open javierhonduco opened 1 month ago
I agree that for this kind of library including async support makes a lot of sense. My main worry, as you said, is that having both sync and async paths tends to be somewhat complex and a trade off on many fronts. But many libraries manage to do it. An article that I read some time back summarizing approaches is https://nullderef.com/blog/rust-async-sync/ Perhaps there are some lessons to be taken away from it.
Cool, thanks for the link, I'll take a look and see if I can wrap my head around the async world 😄
Hi, hi!
Would you consider adding async support to this crate? This is no a deal-breaker for me but I am evaluating this crate in an async environment (using tokio) and this could be a nice addition. I am not sure what's the story like for Rust libraries supporting both sync and async code... Seems a bit messy, and my async Rust skills are not good enough to be able to assess this well.
Currently using this library without spawning
tokio::task::block_in_place
can cause runtime panics. Currently investigating this, but will update the issue once I understand this a bit better.