Thoughts on async?
fenollp opened this issue · comments
I'm doing some networking (with tonic) and I'm ending up with a tokio runtime and async fns.
I see ApplicationContext::new expects non-async function pointers and uses std::sync::mpsc{Sender,Receiver}.
Connecting my networking stuff and appctx callbacks is a bit awkward: it involves a mutex and some thought to give to the Receiver (which does not implement Send).
Are there any plans to move to using async functions in ApplicationContext?
tokio has Send MPSC channels.
Communication could be thread-safe I guess?
I'm more concerned over the inconvenience that using async with libreMarkable is right now.
I don't have any concrete plans for async functions in ApplicationContext however it is something that definitely makes sense at this point. I'd happily merge it if you have something working. The main reason I didn't take that route earlier was because back then the ecosystem revolving around async runtimes was more hectic than it is now.
Like you pointed out, tokio's MPSC channels should fit the bill quite nicely. Rust actually makes it clear where these boundaries are and basing communication on top of any async runtime of your choice would be a great start.
@LoganDark mentioned this as well.
Personally would like to do before:
- Reduce reliance on panics/expect/unwraps significantly
- Reduce some thread reliance (e.g. use a single thread for all EvDevices at once)
After this, we can consider how to best implement this and make the changes as lightweight, conditional and easy to understand as possible while also preventing to have many things implemented twice.