conn.interact(move|conn|{ |
sync::sync_library(conn,&root,&sender,full); |
}) |
.await |
Closures provided to conn.interact(..) are run on a separate thread by deadpool, so spawn_sync isn't blocking the UI, it should just be idle awaiting for this interact call to complete. The UI should be updating when it gets messages from this thread.
It could be due to how the glib main loop prioritizes tasks. As far as I know the actual redrawing of the UI in GTK doesn't happen right away when something changes, but is instead queued on the main loop to run when it's idle. So then in the handle_updates function here:
asyncfn handle_updates(&self,receiver: Receiver<ProgressUpdate>){ |
whileletOk(update)=receiver.recv().await{ |
matchupdate{ |
ProgressUpdate::Total(n)=>self.emit_by_name::<()>("sync-started",&[&n]), |
ProgressUpdate::Progress=>self.emit_by_name::<()>("sync-progress",&[]), |
I'm guessing that the main loop only goes idle when that await on the receiver is pending waiting for a new message, so if a new progress update happens to arrive before the previous one is finished being handled the main loop never goes idle and never switches to processing all the UI updates that are getting queued up.
I've just tried changing the handle_updates function to run as a low-priority idle task that only checks for progress updates when it runs, instead of waking up and taking priority whenever there is a progress update, so theoretically the main loop should prioritize UI updates more this way. Not sure if it fixes it completely because I didn't have this issue happening on my devices to confirm a difference. (probably just due to how async timing happens to work out on different CPUs or something)
On a related but slightly separate note, why have you used deadpool instead of r2d2, which comes as a feature of diesel? Just curious.
I used deadpool over r2d2 because deadpool has better async integration. With r2d2 everything is blocking/non-async, and in general it seems more designed for multi-threading situations, while deadpool uses all async functions that felt more ergonomic to use since I was already using async code everywhere. Deadpool manages it's own threadpool internally for each connection and exposes an async interface rather than you having to spawn threads/async tasks manually.
manan-gup commented
The progress bar for the full library rebuild stays at zero throughout the rebuilding process and only moves once the task is complete.
smol::future::zip(self.handle_updates(receiver),self.spawn_sync(full,sender)).await;I think it's probably because the
spawn_syncmethod needs to run on a separate thread as it's doing a lot of work and that's likely blocking the UI from updating.On a related but slightly separate note, why have you used
deadpoolinstead ofr2d2, which comes as a feature ofdiesel? Just curious.