4 ms·

The general idea of types with a fixed layout seems great, but I'm a lot more dubious about the idea of unsafe blocks. The web is supposed to be a sandbox where

The general idea of types with a fixed layout seems great, but I'm a lot more dubious about the idea of unsafe blocks. The web is supposed to be a sandbox where we run untrusted code and with pretty good certainty expect that it can't crash the computer. Allowing untrusted code to specify "hey let me do stuff that can cause data races if not done correctly" is just asking for trouble, and also exploits. If shared structs are going to be adopted I think they probably need to be immutable after creation, or at the very least only modified with atomic operations.

jitl 2y ago
The unsafe block doesn't actually do anything at all. It's just pointless cargo-cutling from Rust.
jsheard 2y ago
Isn't it really no different to what you can already do with WASM threads though? C/C++ or unsafe Rust compiled to WASM can have data races, but the worst it can do is crash the WASM instance, just like how you can have use-after-frees or out-of-bounds array accesses in WASM but the blast radius is confined to the instance. Granted, a JS runtime is significantly more complex than a WASM runtime so there is more room for error.
- titzer 2y ago
  > crash the WASM instance I guess it depends on how you get to said crash, but no, data races on Wasm shared memory cannot "crash" anything. At worst racy reads/writes can produce garbage (primitive) values and put garbage bits into memory locations involved in the accesses. Putting garbage bits into a Wasm memory could lead to a program's logic having bugs (e.g. it could then try to access out of bounds or trap for another reason), but the accesses themselves can't crash anything.
- leoh 2y ago
  This is a good point, I think, in that — on account of wasm — there is really an opportunity for new languages in the browser
modeless 2y ago
SharedArrayBuffer can already do data races on the web. And they can't crash the browser or computer.
pjmlp 2y ago
That was gone with GPU access and WebAssembly.
paulddraper 2y ago
It's not unsafe as in "memory segmentation fault" unsafe. It's unsafe as in, if you don't follow the rules, the resulting value is ~rand(). For those familiar with C/C++ terminology, this is the tame "unspecified behavior" (not the nasal demon "undefined behavior.")
- badmintonbaseba 2y ago
  Nit: "unspecified behavior" isn't a thing, at least without some further qualifications. It's usually "unspecified result", or "unspecified result or trap" for certain operations. "unspecified behavior" without further qualifications is just "undefined behavior". Having said that, an "unspecified result" can still come from anywhere, like a value left in a register from some previous computation or other "garbage" on the stack or heap. This still can be a security issue, even though the behavior is not completely undefined.
  - paulddraper 2y ago
    Nit nit: Unspecified behavior is absolutely a thing, reference ISO/IEC 14882:2003 §1.3.13 Unspecified Behavior. The rest is correct.
syg 2y ago
Author here. I hear your feedback about unsafe blocks. Similar sentiment is shared by other delegates of the JS standards committee. The main reason it is there today is to satisfy some delegates' requirement that we build in guardrails so as to naturally discourage authors from creating thread-unsafe public APIs and libraries by default. We're exploring other ideas to try to satisfy that requirement without unsafe blocks.
- bastawhiz 2y ago
  There's already a precedent of ownership on transferred objects. Why not have an `.unsafe(cb)` method on the structs? Error if you don't have ownership, then use the callback to temporarily acquire ownership. At least to me, it's more intuitive and seems idiomatic.
- nox101 2y ago
  bike-shedding but you should consider renaming them from "unsafe" to "volatile" or some other word that expresses that they are not unsafe to the user/browser/os. They are only changeable by other threads. The word "unsafe" will be picked up as meaning "can infect your computer" which we can already see examples of these messages.
syg 2y ago
The ability to do unordered operations on shared memory is important in general to write performant multithreaded code. On x86, which is very close to sequentially consistent by default (it has something called TSO, not SC), there is less of a delta. But the world seems to be moving towards architectures with weaker memory models, in particular ARM, where the performance difference between ordinary operations and sequentially consistent operations is much larger. For example, if you're protecting the internal state of some data structure with a mutex, the mutex lock and unlock operations are what ensures ordering and visibility of your memory writes. In the critical section, you don't need to do atomic, sequentially consistent accesses. Doing so has no additional safety and only introduces performance overhead, which can be significant on certain architectures.

jitl 2y ago

The unsafe block doesn't actually do anything at all. It's just pointless cargo-cutling from Rust.

jsheard 2y ago

Isn't it really no different to what you can already do with WASM threads though? C/C++ or unsafe Rust compiled to WASM can have data races, but the worst it can do is crash the WASM instance, just like how you can have use-after-frees or out-of-bounds array accesses in WASM but the blast radius is confined to the instance. Granted, a JS runtime is significantly more complex than a WASM runtime so there is more room for error.

titzer 2y ago
> crash the WASM instance I guess it depends on how you get to said crash, but no, data races on Wasm shared memory cannot "crash" anything. At worst racy reads/writes can produce garbage (primitive) values and put garbage bits into memory locations involved in the accesses. Putting garbage bits into a Wasm memory could lead to a program's logic having bugs (e.g. it could then try to access out of bounds or trap for another reason), but the accesses themselves can't crash anything.
leoh 2y ago
This is a good point, I think, in that — on account of wasm — there is really an opportunity for new languages in the browser

modeless 2y ago

SharedArrayBuffer can already do data races on the web. And they can't crash the browser or computer.

pjmlp 2y ago

That was gone with GPU access and WebAssembly.

paulddraper 2y ago

It's not unsafe as in "memory segmentation fault" unsafe. It's unsafe as in, if you don't follow the rules, the resulting value is ~rand(). For those familiar with C/C++ terminology, this is the tame "unspecified behavior" (not the nasal demon "undefined behavior.")

badmintonbaseba 2y ago
Nit: "unspecified behavior" isn't a thing, at least without some further qualifications. It's usually "unspecified result", or "unspecified result or trap" for certain operations. "unspecified behavior" without further qualifications is just "undefined behavior". Having said that, an "unspecified result" can still come from anywhere, like a value left in a register from some previous computation or other "garbage" on the stack or heap. This still can be a security issue, even though the behavior is not completely undefined.
- paulddraper 2y ago
  Nit nit: Unspecified behavior is absolutely a thing, reference ISO/IEC 14882:2003 §1.3.13 Unspecified Behavior. The rest is correct.

syg 2y ago

Author here. I hear your feedback about unsafe blocks. Similar sentiment is shared by other delegates of the JS standards committee. The main reason it is there today is to satisfy some delegates' requirement that we build in guardrails so as to naturally discourage authors from creating thread-unsafe public APIs and libraries by default. We're exploring other ideas to try to satisfy that requirement without unsafe blocks.

bastawhiz 2y ago
There's already a precedent of ownership on transferred objects. Why not have an `.unsafe(cb)` method on the structs? Error if you don't have ownership, then use the callback to temporarily acquire ownership. At least to me, it's more intuitive and seems idiomatic.
nox101 2y ago
bike-shedding but you should consider renaming them from "unsafe" to "volatile" or some other word that expresses that they are not unsafe to the user/browser/os. They are only changeable by other threads. The word "unsafe" will be picked up as meaning "can infect your computer" which we can already see examples of these messages.

syg 2y ago

The ability to do unordered operations on shared memory is important in general to write performant multithreaded code. On x86, which is very close to sequentially consistent by default (it has something called TSO, not SC), there is less of a delta. But the world seems to be moving towards architectures with weaker memory models, in particular ARM, where the performance difference between ordinary operations and sequentially consistent operations is much larger. For example, if you're protecting the internal state of some data structure with a mutex, the mutex lock and unlock operations are what ensures ordering and visibility of your memory writes. In the critical section, you don't need to do atomic, sequentially consistent accesses. Doing so has no additional safety and only introduces performance overhead, which can be significant on certain architectures.