Using !Send with the benefits of Send
summary
Evaluates concrete ways to drive non‑Send futures alongside Tokio’s work‑stealing runtime using a real TDF render path that depends on MuPDF and new PDF C/C++ bindings, reports a segfault on quick test when naively sending non‑Send data, measures tradeoffs of local_set (blocks stealing), local runtime / local_pool_handle (scales, 4/5 but isolates runtimes), prototypes a thread‑local “send‑correcting” wrapper, and concludes no current solution meets all requirements so a runtime API like spawn_local in runtime is needed.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 0:15Who I am and what I work on
- 1:57TDF architecture overview
- 2:37Non-async render challenge
- 4:43Manual future benefits
- 6:27Send in Tokio runtime
- 7:30Desired non-Send future
- 8:34Evaluating local set
- 9:38Evaluating local runtime
- 10:42Evaluating local pool handle
- 11:44Custom Send-correcting future
- 14:54Limitations and future work
- 16:17Better async FFI bindings
related talks
45mKeynote | Actors with Tokio – a lesson in ownership
31mThrough the Fire and the Flames
18mA better way of doing Async Rust
06mZero-copy Transfers with io_uring and Rust
01h 01mC++ Sender Patterns to Wrangle C++ Concurrency in Embedded Devices
01h 05mLet's write an async runtime
05m“Using async-profiler to Find Tail Latency Issues”
57m[filtered] Asynchronous C++ Programming