Interest in async rust

[andrewdavidmackenzie]

Just a query really about async rust and rppal.

As you know (from previous issues and conversations) I'm using rppal in my pigg project for a UI for local and remote GPIO hw control.

I used Iced for the UI ("piggui"), and like most UI frameworks it's heavily async. I have a command line version ("piglet"), and to be able to share a lot of the code I decided to go async also (both use Tokio).

For the input callback (set_async_interrupt) I know that is on a separate thread and calls the synchronous callback. I have to jump thru some hoops to get the call back to update the UI, with sync function using block_on() to call an async UI sending function (future_sender...).

I looked at async closures for the callback (still unstable, but in testing) but that can't work as the rppal code calls it.

So, I have two questions about rppal and async that will depend on your interest on spending more time on the crate or not:

• interest to explore adding a function to pass an async closure for reporting input changes? (Could reduce number of threads created as well as simplifying interfacing from the callback into an async app)

• interest in exploring adding more async functions in rppal in general?

Thanks for your thoughts.

[golemparts]

I appreciate the suggestion. RPPAL is currently in maintenance mode, which is something I need to make clear in the README to better set expectations. I haven't actively used it in my own projects for several years, and am maintaining it just to add new Pi devices, fix bugs and implement required changes. RPPAL is feature-complete, and my only remaining goal is a 1.0 release at some point.

I can see the benefits of an async RPPAL from the standpoint of using it with other async frameworks. However, pretty much all (unless something slipped my mind) of its current functions either return immediately, or have a non-blocking alternative. As such, RPPAL itself won't benefit from being async. Considering that and the current status of the project, implementing a wrapper inside your project, or alternatively creating an async RPPAL crate as a wrapper around this crate, would be the preferred ways of dealing with this.

[andrewdavidmackenzie]

Understood. The main area where I have an impedance mismatch with the rest of my async app, and where I see some advantages for rppal itself is related to set_async_interrupt() where you create a new thread for each one set, and then do a call back to the sync callback passed in.