tauri-apps / tauri-apps/tauri-docs
[docs][bugfix] document that tauri's async_runtime is "blessed"
Nobody has claimed this yet.
- Dominant language
- MDX
- Stars
- 1.1k
- Forks
- 887
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 48
Description
Tauri's async_runtime docs currently say that it "rexports" tokio's methods. This is not accurate, it wraps them.
If one directly uses a spawn from tokio one would expect equivalent semantics. However, Tauri's async runtime initializes a RunTime if one does not exist. This can lead to application panics in surprising ways if Tokio's methods are not used directly.
This adds a (negligible?) overhead to spawn calls, but more importantly, makes it so that examples of calling spawn can accidentally panic if the runtime does not exist yet.
To ameliorate the issues, I suggest updating the docs to not read "re-exports" and/or launching a runtime more explicitly if async is to be used, or making the spawn methods be actual re-exports.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Locate the async_runtime documentation and read the surrounding explanation of its relationship to Tokio. Verify the current “re-exports” wording against the runtime behavior described in the issue; the documentation is done when it accurately explains the wrapping and runtime initialization implications.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100