Wrap Tokio types in a configurable runtime - #310
Merged
Merged
Conversation
|
|
mikayla-maki
force-pushed
the
cross-rt
branch
from
February 20, 2024 18:23
d145f31 to
532591e
Compare
mikayla-maki
force-pushed
the
cross-rt
branch
from
February 26, 2024 23:56
e1f071e to
1746ddc
Compare
mikayla-maki
marked this pull request as ready for review
February 27, 2024 00:02
mikayla-maki
force-pushed
the
cross-rt
branch
from
February 28, 2024 05:27
cfd6bec to
aee71bb
Compare
mikayla-maki
force-pushed
the
cross-rt
branch
from
February 28, 2024 05:28
aee71bb to
b3cf18a
Compare
theomonnom
approved these changes
Mar 26, 2024
theomonnom
left a comment
Member
There was a problem hiding this comment.
nice! lgtm, going to test the changes with the python-sdk and merge the PR
thanks!
| // and print all incoming events | ||
|
|
||
| fn main() { | ||
| async_std::task::block_on(async { |
This was referenced Jun 19, 2024
This was referenced Aug 27, 2026
Merged
1egoman
added a commit
that referenced
this pull request
Aug 31, 2026
## Background The `livekit-runtime` crate was [introduced in ~2024 by the folks at zed](#310) so they could use `livekit` in zed, which wasn't using a tokio runtime (my understanding is, a completely custom runtime!). The general design patterns haven't really changed since then. A few pain points that have been encountered recently touch on `livekit-runtime`: 1. The migration wasn't done completely, and there are quite a few tokio runtime specific calls which were missed (or introduced later inadvertently). One example I know of offhand is [the `tokio::fs` usage in the `send_file` data stream method](https://github.com/livekit/rust-sdks/blob/6078e6aed5df72c5e6613e76729f096964fbe894/livekit-data-stream/src/outgoing/manager.rs#L290). These could be fixed piecemeal, but we'd need to extend the abstractions further to deal with a bunch of different async operations which is fairly burdensome. 2. Because of 1, today, the `async` and `dispatcher` features (what zed was using specifically) don't actually build on `main` properly 😞 . 3. We should be testing to ensure that all feature combinations build in ci, but in order to do this with the current design of `livekit-runtime` (which isn't super well encapsulated - higher level features in the `livekit` crate sometimes imply certain runtimes), it would be challenging. We'd have to effectively do a build for each `platform` x `runtime` x `ssl configuration` x any ad hoc features which is impractical. 4. `async-std` (which the `async` feature enables) has recently been deprecated in favor of `smol`, which we don't support today. From what I can tell looking through zed's code, they seem to have since migrated from the custom runtime approach they were using to a [more typical looking tokio backed approach](https://github.com/zed-industries/zed/blob/1e2e422c7b33b28eab0a948e442334198f3b6d27/Cargo.toml#L674). It also looks like they [might be using](https://github.com/zed-industries/zed/blob/1e2e422c7b33b28eab0a948e442334198f3b6d27/Cargo.toml#L979) a [rust-sdks fork, not actually mainline](https://github.com/zed-industries/livekit-rust-sdks). I've done a search across all of github, and the only places that `dispatcher` seems to be used is by stale zed forks, so I'm fairly confident this can be dropped with little to no consequence. ## Summary Given this context and socializing this decision with the client team, we have decided to **drop** support for non tokio async runtimes. `livekit-runtime` will be deprecated and all non tokio shim code will be removed. This will address all points above (fewer features making testing easier, no need to support `async-std`, and ci validates the crate will always compile on tokio) and lead to a much simpler to maintain project. If we decide eventually that it's worth reintroducing this behavior, then #1369 would be a good place to start, along with taking some learnings from https://webrtc.rs/blog/2026/01/31/async-friendly-webrtc-architecture.html. ## TODO - [ ] Publish a final `livekit-runtime` release marking it as deprecated.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds a thin compatibility layer over the rust runtime ecosystem.
TODO:
Switch from async default to tokio defaultN/A, CI is currently broken