Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Thoughts on async? #40

Open
fenollp opened this issue Sep 10, 2020 · 2 comments
Open

Thoughts on async? #40

fenollp opened this issue Sep 10, 2020 · 2 comments
Labels
discussion Discussion encouraged. If this is preparation for a PR, it likely has no agreed implementation yet. enhancement New feature or request

Comments

@fenollp
Copy link
Collaborator

fenollp commented Sep 10, 2020

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.

@canselcik
Copy link
Owner

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.

@LinusCDE
Copy link
Collaborator

@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.

@LinusCDE LinusCDE added discussion Discussion encouraged. If this is preparation for a PR, it likely has no agreed implementation yet. enhancement New feature or request labels Jan 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Discussion encouraged. If this is preparation for a PR, it likely has no agreed implementation yet. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants