Skip to content

fix(ui): read and parse torrents off the GTK thread - #556

Merged
Linuxuser67 merged 2 commits into
mainfrom
fix/torrent-parse-off-thread
Oct 28, 2026
Merged

Linuxuser67 merged 2 commits into
mainfrom
fix/torrent-parse-off-thread

Conversation

@Linuxuser67

Copy link
Copy Markdown
Owner

Moves .torrent read+parse into gio::spawn_blocking at all three UI-entry sites, matching the convention already used by the enqueue path (download.rs:1027).

  • wire_torrent_picker: was reading (≤10 MB) and parsing inside glib::spawn_future_local.
  • handle_open_files: read was already off-thread, but torrent_file_list ran on the main loop after the await.
  • intake_remote_torrent: same parse-on-main-loop after the remote fetch (not flagged by the review, same class).

No behavior change: same picker-vs-enqueue decision, same error messages, and the exact bytes that parsed are the bytes handed to the picker/enqueue.

Found while verifying a review finding. That review also claimed resolve_gallery_auth runs on the GTK thread via dual_probe; it does not — dual_probe is spawned with tokio_rt().spawn at inline_add.rs:359, so no change was made there.

houssemko added 2 commits October 28, 2026 14:24
Move torrent archive hashing into the restore blocking pool, dedupe the
read+parse closure behind torrent::load_torrent_file, and log JoinError
payloads instead of dropping them.
@Linuxuser67
Linuxuser67 merged commit 349b248 into main Oct 28, 2026
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant