Would it make sense to support no_std + alloc?

[TheButlah]

Would it make sense for this crate to support no_std + alloc? I thought of smol when searching for a async executor in embedded rust.

[notgull]

This crate uses Mutexes to secure its interior data, so it would be difficult to port to no_std. That being said, I would accept a PR that replaces the mutexes if it doesn't show a regression, as long as it doesn't use spinlocks.

That being said async_task is no_std, so it might be better to build your own executor around that abstraction.

[notgull]

I'm closing this for now, since we're not planning on moving in this direction. Thanks anyways!

[TheButlah]

FWIW i've been successfully using embassy for an embedded async executor.

[notgull]

FWIW i've been successfully using embassy for an embedded async executor.

Yes, I'd probably recommend embassy for most cases if you're using embedded targeted for async. Right now, in Stable Rust, it's probably not impossible to write a task/executor abstraction that works for both desktop and embedded, but it would be very hard and you'd end up with either a task abstraction that works well for embedded but not for desktop or vice versa.