Would it make sense to create a runtime dedicated to single-threaded, extremely simple use cases?

[bradleyharden]

Hi,

I recently read @notgull's post about why you might actually want async in your project. It resonated with me. I had a project that I recognized as implementing async patterns, and I used an async runtime in my tests (see my related question), but I ended up not using a runtime in my actual project. I wanted to discuss why I made that decision, to see if there is potentially room for further work on smol or another project.

My project was implemented in an embedded Linux context, and it's job was to shuttle data bidirectionally between a Unix socket and a serial port. I wanted to keep the implementation as simple as possible, so I was pretty turned off when I started looking at the internals of Tokio. I just didn't need that level of complexity for literally two byte streams.

At the time, I hadn't given smol much thought. Instead, I manually implemented an event loop using mio. It worked, but I think using a proper async runtime would have been more ergonomic.

When I eventually looked at smol, I found that the async_io::block_on function is pretty close to what I had imagined of a minimal runtime. However, it still spawns a second thread, and it still assumes a potentially multi-threaded design. In my case, I had no desire to use multiple threads. It just wasn't necessary to handle a serial port operating at 115,200 baud.

I began to wonder if there is room for something even smoller than smol, something explicitly designed for single-threaded, extremely simple use cases. It wouldn't need locks or any other synchronization. It would just poll some futures and then block on epoll_wait or equivalent.

Do you see that as a use case worthy of a dedicated library? Or is it so simple that it can be left to manual implementations like mine?

[notgull]

I wrote unsend a few months back, but it doesn't implement a reactor. I didn't do this largely because I just used futures_lite::future::block_on in my tests, or just used async_io::block_on. It wouldn't be too hard to implement an async reactor based on unsend, I'd think.

[bradleyharden]

Interesting. I'll have to dig into the implementation of unsend.

In the README, you discuss implications of the requirement that Wakers be Send + Sync. Rather than work around that limitation, using your current approach, would it instead be possible to simply make Executor::new unsafe? The contract would require you to never send anything to another thread. To me, that seems like a better approach than an awkward workaround. If the whole point of unsend is for !Send use cases, I don't think anyone would be upset that it is enforced via an unsafe contract.

Although maybe it's not that simple? Still, personally, I would rather opt in to some contract with unsafe to get the ideal implementation for these sort of niche use cases.

[notgull]

In the README, you discuss implications of the requirement that Wakers be Send + Sync. Rather than work around that limitation, using your current approach, would it instead be possible to simply make Executor::new unsafe? The contract would require you to never send anything to another thread. To me, that seems like a better approach than an awkward workaround. If the whole point of unsend is for !Send use cases, I don't think anyone would be upset that it is enforced via an unsafe contract.

In theory this would work. In practice it's generally pretty hard to guarantee that Waker doesn't get sent to another thread. Especially hard on embedded devices, where what does and doesn't count as a separate execution context gets a bit blurry. It's pretty easy to call a future that stores the waker somewhere where another thread picks it up.

So, it would require some finesse.

[notgull]

To directly answer your question: I would think that it's definitely possible to implement this functionality in terms of a library. It would probably be useful, not only for embedded cases like you said but also cases where data is !Send anyways (like in GUI programming on MacOS).