Recommendations for integrating a long-running task into Iced?

[sowbug]

I could use some help choosing the right path for an asynchronous or threaded design of my Iced-based app.

I'm designing a DAW (digital audio workstation). If that's an unfamiliar term to you, the main part is a long-running, near-real-time task that generates a stream of audio samples (typically 44.1KHz). This design is interactive (not all DAWs are), so it shouldn't buffer more than a few milliseconds of samples. The audio is generated by an arbitrarily complex set of user-specified components. Those components are also viewable in real time; they update as the project renders. Some components' UI can be fairly rich; for example, they might display an animation calculated from thousands of audio samples, and the update frequency could be similar to video games.

This project started out with a completely synchronous, single-threaded backend with nothing but a CLI. Now I'm tacking a frontend onto it. I've implemented update() and view() for most of the components, as well as for the master "orchestrator" that assembles all the components into a coherent audio stream. I didn't want to dive into threading or asynchronous programming while I was vetting Iced, so I naively added a Tick message to the app, much like the Game of Life example, to give the backend a chance to work. Every few milliseconds it generates enough audio samples to stay ahead of the machine's audio output. This approach was enough to unblock progress, but I'm now ready to do this right.

Some of the (failed) approaches I have taken:

• Backend in a thread. Spawn a single long-lived thread that generates audio. The app communicates with it (play/stop/seek etc.) by an mpsc channel. This worked great until I tried hooking the components' view() methods back up to the Iced portion of the app. I started by wrapping an Arc<Mutex<>> around the orchestrator (which owns all the audio components and is in turn owned by the Iced Application instance), and updated the backend loop to grab and then release the mutex each time. Unfortunately, I then discovered that the borrow checker doesn't like when the Element that view() returns came from a temporary receiver (if let Ok(o) = orchestrator.lock() { o.view() }). I think I can work around this by changing the view() method signature to indicate that the lifetime of the returned Element corresponds to something other than the temporary receiver, but no other Iced examples seem to need to do that, which seems like a smell that this approach is wrong.
• Async/await. Convert the orchestrator's main work method to be an async function and schedule it through Command::perform(self.worker.work(), Message::WorkDone) (or have it return an Option<Future>, which I think is equivalent). I haven't been able to get this to compile, because I'm too new to Rust to figure out how to do that without a borrowed data escapes outside of associated function error. Most of Iced's Command::perform() examples call argument-free functions, not methods on self, so it seems perform() is more for context-less setup or initialization, or Lisp-y pure-function work, than for continuation of long-running work. (I did see that Game of Life manages to call perform() with arguments, but as far as I can tell it clones Life to avoid retaining any references outside the closure. That wouldn't work for my application, because Orchestrator owns too much data, and the inner cycle time is too short.)
• Subscription. This seems like an excellent approach, except how do I call view() on the thing providing the subscription stream? I don't think I can, at least not without getting into the same issues that the backend-in-a-thread approach found.

Intuitively, it doesn't seem that farfetched to design a system that says "do your work as fast as you can, but check this [thing] for incoming requests, post to that [thing] to provide status updates, and be ready to stop the world from time to time and handle a view()."

Other ideas I'm thinking of:

• Give up on view() being implemented by the components, and move it closer to the frontend, making it generate the view using component getters. This makes me sad, but maybe that's the same sadness that anyone raised on OO feels when they move to Rust. It does feel like an enormous price to pay just because I can't figure out how to call view() on a wrapped struct. But I might be falling into the "Actively trying to make components is a recipe for disaster in Elm" trap, and it's actually fine to put the view() logic elsewhere.
• Stay synchronous. My design constraints call for an inner loop of 22usec, and at most I'd expect Iced to run at 60fps. There isn't really a "long-running" task when you look at it that way. But it seems like a limiting design choice. I won't be able to take advantage of extra CPU cores, and I'm depending on my own skill as a programmer to keep UI and background work balanced so that neither ever causes the other to get choppy. And this whole project started out by a desire to learn Rust, and I'd rather not my lesson about async/threading be "it was too hard."
• Something more drastic like keeping the guts of the project in a CLI running in its own process, and teaching the Iced app to talk to it through IPC. This doesn't solve the view() separation problem, but it sure makes it a lot clearer where the boundaries between model and view should be. It works for Chrome, so speed ought not to be an issue.

Sorry this question is so long, and I'm especially sorry if these are more Rust than Iced questions. I hope the detail I'm providing is useful to recommend an appropriate direction.

[ids1024]

Something more drastic like keeping the guts of the project in a CLI running in its own process

You could do that, but a separate process doesn't inherently give you anything in this case that wouldn't be possible with a thread. Other than that clearer boundary. (Chrome uses processes specifically for secure sandboxing.)

The websocket example uses a subscription that generates events and receives messages over an mpsc channel. It works as an async task but that could easily use a thread by spawning one and using a channel receiver as the stream.

But I guess the complicated part is that you potentially want the view and the background thread to access the same potentially complicated pipeline. That part is easy with just an Arc (not an Arc<Mutex>), until you also want to change it). Though that's perhaps more a general parallel programming problem than a Iced specific one. The most "functional" approach (not necessarily typical in Rust) would be to somehow represent this pipeline in an efficient immutable data structure and pass it to the backend. With a mutex, the view could clone anything it needs so the lock can be freed when it returns, which may or may not be efficient enough.

[sowbug]

Thanks! I actually did a prototype of a threaded subscription yesterday, which seems to work for the non-view() part of the problem. I am pretty sure I haven't coded it correctly, because it needs a weird statement to get the background job's thread to clean itself up properly. I suspect I'm running into the same issue as #1348, and I admit I don't understand what was wrong about that issue creator's original code or why @hecrj said "keep in mind that your Subscription is still incorrect and will not work as you expect it to." (By the way, I seemed to have hit an infinite loop as well before adding that .await, which means either #1349 isn't fixed, or I've discovered a new way to cause similar behavior.)

I'm going to resurrect my threaded subscription prototype and try a new version of view() that lives in the app and uses Arc-wrapper component getters to build the view. Maybe that separation won't be as painful as I'm imagining.

I'm not going to mark this question answered just yet, because it still feels like a discussion. Stay tuned...

[sowbug]

This one looks a lot better: https://gist.github.com/sowbug/93a0187a7c3038e09d73270cd97184b5

It builds Thing's view in the app's view(), and I fixed a goofy bug where I was getting the mpsc channel's next message improperly. (vscode and rust analyzer are amazing, but if you depend on them to browse an API, then if you forget to import a trait, you won't see all the available methods.)

I haven't been able to break this version. It is responsive and fast. I still have that quirky iced::futures::future::pending().await line in there, but I'm feeling a little better about it because I now think it exists because Futures need to end or await, and this subscription state machine doesn't seem to have a way to end in a Future sense -- you merely tell the runtime what your next state is, and hope that the app figures out to unsubscribe from you. I still don't get what you're supposed to do if you really don't have anything left to await on.