Hacker News Reader

Comment by connicpu | Hacker News Reader

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.

View on HN

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.

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.

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.

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.

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.

> 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.

This is a good point, I think, in that — on account of wasm — there is really an opportunity for new languages in the browser

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

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.")

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.

Nit nit: Unspecified behavior is absolutely a thing, reference ISO/IEC 14882:2003 §1.3.13 Unspecified Behavior.

The rest is correct.

That was gone with GPU access and WebAssembly.

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

Reply on news.ycombinator.com