Using WebAssembly threads from C, C++ and Rust
web.dev
web.dev
This means WASM threads can't be used with popular hosting solutions like Github Pages, which in turn means that for library authors like me the feature is nearly useless because it splits the audience into people who have control over their web servers, and those who don't, which in turn means maintaining two code paths, one with and one without threading support. And even if you theoretically have control over the web server configuration it's still more hassle because the people who write the code are usually not the same people who configure the web servers. So instead of just dumping a couple of WASM files to IT you also need to find and ask the right people to tweak the web server configuration just for your use case.
Sometimes I don't understand what's going on in the heads of the people thinking this stuff up :/
The more relevant question here is why so few (if at all) web hosting solutions allow the user to configure custom server rules?
Why would communicating sequential processes be crippled by this?
Something like
<head>
<meta http-equiv="Cross-Origin-Embedder-Policy" content="require-corp" />
<meta http-equiv="Cross-Origin-Opener-Policy" content="same-origin" />
...
</head>https://stackoverflow.com/questions/67259043/can-coop-coep-h...
So this post made me look up[1][2] COOP/COEP, but as far as i can tell this seems to be a security measure. Seemingly because they don't know, at this point in time, how else to enable shared memory in WASM without this limitation.
So what in your mind could have been done better? I agree it really sucks having your WASM apps live in two camps, single and multithreaded, but it seems like we, as users conceptually have two choices:
1. Don't get shared memory at all. Or, 2. Get shared memory in limited scenarios
#2 still seems better than #1, no?
Or do you perhaps think the performance Opt-In is overly aggressive. Ie if we just enabled shared memory always we'd reduce the WASM split with minimal issues. Alternatively we could do the reverse, Opt-Out, such that for resource constrained environments the phone/whatever could connect to `mobile.example.com`.
[1]: https://web.dev/coop-coep/ [2]: https://www.youtube.com/watch?v=XLNJYhjA-0c&t=4s
The underlying problem is that this is a classic finger-pointing-situation that will probably never be fixed, because the web security people point the finger at the web hosters, and the web hosters shrug it off because 99% of their customers don't need the features because they just host their static blog there.
If it's a security risk, there shouldn't be an option. Setting up a web server is a low bar for malicious actors.
HTTP headers should not affect app functionality in this way.
I could use something like Netlify, but I like the convenience of the gh-pages branch and deployment.
Just like CORS proxies maybe someone can make a public COOP/COEP proxy.
Stupid requirements will lead to stupid workarounds.
Actually you could probably just use CloudFront if you don't mind spending a couple bucks a month and configure it to add some headers.
When looking at the title, I thought the article was about running a WASM module in a separate thread from a c/c++/rust program. For example: https://github.com/WebAssembly/wasm-c-api
However, after reading it, it seems to be the opposite.
It's about running a WASM module that has thread usage, implemented in c, c++ or rust. Then in that situation, I think the title should be rephrased as:
Running WASM threads written in C, C++ or Rust.
is it me or the use of "from" is misleading? is it "executed by/called from" or "compiled from" ?
Sorry for asking this unrelated question. As a non-native speaker, every time I have this type of situation, I start to self-doubt.
I don't think the original title is bad. The ambiguity as to whether the C/C++/Rust code is guest or host seems natural to me.
WebAssembly is the platform (aside: and an assembly langauge) that provides WebAssembly threads. It makes sense to say "use posix threads from C or C++". Posix is underneath whatever language you use.
Saying "running posix threads written in C or C++" seems to suggest that someone is running their own custom threading library in C or C++.
Yes, wasm is a platform, but c++ runtime can also be a platform. You could build a c++ runtime/compiler into wasm to compile and run c code. Or you could embed a wasm runtime into a c++ program (i.e. the github project I mentioned.) you can run linux vm inside a windows host, or you can run a windows vm inside a linux host, which one is the platform?
And what if we say "use posix threads from rust"? I would interpret it as a rust program calling a posix threads, perhaps implemented in c. or a rust program calling a rust crate wrapping posix thread.
As far as I can tell, “threads” from a WebAssembly implementation's perspective is just the combination of SharedArrayBuffer and atomics; support for the actual threading comes from Web Workers which are already a separate standard. Compilers like Emscripten then use the combination of the three to implement threading.
I use `Atomics.wait` and `Atomics.compareExchange` and maybe a couple other APIs and it works well on Safari Technology Preview (if you enable SharedArrayBuffer).
FWIW that's exactly what the linked post describes :)
https://developer.apple.com/safari/technology-preview/releas...
https://github.com/w3reality/wasm-mt
It's just that with sharedarraybuffers and atomics we unlock better performance and can match APIs of native OSes. But that's okay, we can still have a fallback for Safari (specially if we can architect the app so the threads only communicate by passing messages) and it shouldn't be a big deal.
At what point people decided HTML/CSS/JS is the epitome of user interaction for dynamic applications such as document editing, mapping and routing, media playing, chatting...?
Another factor is cross-platform apps. Web app is still the most cross-platform solution. Also you can create and update web apps without gatekeepers approval.
But nail in the coffin IMO was Steve Jobs, who decided not to adopt nor Flash, nor JVM in mobile Safari.
So, it wasn't for lack of trying. Javascript won by default, just by being slightly less nasty. Many of us run (selective) Javascript blockers to keep it from being too nasty. They don't always succeed.
Perhaps, but I don't spend a lot of time installing applications, nor am I concerned about megabytes of disk usage. None of the web applications I use do anything particularly interesting - all of the interesting applications I use are not web apps.
Web apps give maximum convenience to developers and sysadmins and in some cases, this is a worthwhile tradeoff, but often enough it just makes for an inferior product.
The world people (like you) seem to want is one where the web is essentially dead and everyone just sits around in some subset of waller gardens that they don't really leave, with some minimal amount of hyperlinks available to get content in and out of other products. I have a link to a map, well, you better have Google Maps installed or it won't work. That just seems like a depressing failure of vision to me: the goal should be to get the web to the point where it replaces all of these stupid apps we have to have, so no one ever has to decide if an app is "installed or uninstalled" ever again: all content is immediately consumable at all times with nothing other than a URL. And we could be there if people with vested interests--like Apple--didn't stop actively trying to hobble web standards so people were forced to install more apps constantly.
To me, that's not an interesting application. If you want to use the web to share images or videos, that's fine.
If you want to create such content however, why not have a native application that can actually take advantage of the hardware?
> The world people (like you) seem to want is one where the web is essentially dead and everyone just sits around in some subset of waller gardens that they don't really leave, with some minimal amount of hyperlinks available to get content in and out of other products.
Hyperlinks don't necessarily make my life easier. Let's say I want to get <large file> from application A and into application B: The web would just get in the way. I have a file system and all (native) applications can read/write/mmap it. Import/Export workflows exist. It's a solved problem, the web doesn't need to eat everything.
But then how would the largest companies in the world excise a 15% to 30% tax on the entirety of the mobile app market, and soon the desktop app market, as well?
This is no longer true on iOS and hasn't been for at least a couple years.
Browsers are a massive improvement as a platform for developing code, or at least they have the potential to be.
There should be a FOSS OS with powerful OS-level security features, but it just hasn't happened.
This is totally different from the actual capabilities security model, which is closer to a "if you can name a resource you can access that resource". So, for example, imagine every file on your system has a path with a uuid, and there is no "ls" - you'd only be able to access files whose names had been told to you/ that you created yourself.
That's a capabilities model, and Linux does not have that.
Otherwise mobile operating systems have had isolation and a robust native platform for years. It's kinda why mobile apps absolutely exploded and browsers have been desperately trying to keep up for almost a decade now.
Flash on the other hand felt more like a proper programming environment. A shame it was proprietary. And a big shame Adobe didn't open-source Flash Player after discontinuing it.
This isn't how you make a rust closure. It should be `.map(|x| x * x)`. Besides the mistake, it's exactly the example from the readme for rayon.
This stuff is right around the corner, it’s all very exciting. We’re really close to having nearly native performance 3D games in the browser.
If your program has to read a file using fetch the operation is asynchronous. C and wasm doesn't understand this. You cannot await a response inside wasm the same as in JS.
The caveat of asyncify is detailed in the docs: "It is not safe to start an async operation while another is already running. The first must complete before the second begins."[1]
It's a hack, which does work in some instances, but I'm not comfortable putting stack winding hacks into code that's meant to be debuggable. Spooky things could happen.
I'm still looking for alternatives, maybe rust can do it since rust has native async/await support. Haven't quite yet understood what !?!!!?!().?()! Means in rust yet. :)
However, Asyncify is useful in other scenarios - where you want to shim out an API that is normally synchronous in C / Rust land, with an async JS implementation.
async-await, like any coroutine-based mechanism, requires changing every single function in the entire callstack to be async as well, which is usually not feasible in such scenarios (e.g. when shimming out some basic filesystem API). That's where Asyncify helps a lot.