-
Notifications
You must be signed in to change notification settings - Fork 12.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unclear when you need to be in a rust thread #15560
Comments
The library have the notion of a runtime which is provided by all rust tasks. Any service provided by the runtime will require a local task be available. Some examples are:
The public primitives in You may be interested in This definition and line of "what it means to be a task" is constantly evolving over time, so I'm going to close this for now as not particularly actionable. This is somewhat decently covered by http://doc.rust-lang.org/std/rt/ and http://doc.rust-lang.org/guide-runtime.html today, but specific improvements would always be welcome! |
…ustc-to-determine-cfgs, r=Veykril project-model: when using `rust-project.json`, prefer the sysroot-defined rustc over discovery in `$PATH` At the moment, rust-analyzer discovers `rustc` via the `$PATH` even if the `sysroot` field is defined in a `rust-project.json`. However, this does not work for users who do not have rustup installed, resulting in any `cfg`-based inference in rust-analzyer not working correctly. In my (decently naive!) opinion, it makes more sense to rely on the `sysroot` field in the `rust-project.json`. One might ask "why not add `rustc` to the `$PATH`?" That is a reasonable question, but that doesn't work for my use case: - The path to the sysroot in my employer's monorepo changes depending on which platform a user is on. For example, if they're on Linux, they'd want to use the sysroot defined at path `a`, whereas if they're on macOS, they'd want to use the sysroot at path `b` (I wrote the sysroot resolution functionality [here](https://github.com/facebook/buck2/blob/765da4ca1e0b97a0de1e82b2fb3af52766fd06f4/integrations/rust-project/src/sysroot.rs#L39), if you're curious). - The location of the sysroot can (and does!) change, especially as people figure out how to make Rust run successfully on non-Linux platforms (e.g., iOS, Android, etc.) in a monorepo. Updating people's `$PATH` company-wide is hard while updating a config inside a CLI is pretty easy. ## Testing I've created a `rust-project.json` using [rust-project](https://github.com/facebook/buck2/tree/main/integrations/rust-project) and was able to successfully load a project with and without the `sysroot`/`sysroot_src` fields—without those fields, rust-analyzer fell back to the `$PATH` based approach, as evidenced by `[DEBUG project_model::rustc_cfg] using rustc from env rustc="rustc"` showing up in the logs.
Description
I am currently trying to interface with a C library (SDL) which runs on its own thread and need a callback.
First I wanted to use an
Arc<RWLock<DList<T>>>
for this purpose. When confronted with runtime failures, someone on the IRC pointed out to me that anRWLock
can only be used from within a Rust thread.This makes a lot of sense, but was not clear at all from the docs. Maybe it could be pointed out what functions / structures can not be used from a bare
pthread
?(Also, is there a Lock which can be used both from a phtread and from a rust thread?)
The text was updated successfully, but these errors were encountered: