[HN Gopher] Using WebAssembly threads from C, C++ and Rust
___________________________________________________________________
Using WebAssembly threads from C, C++ and Rust
Author : belter
Score : 149 points
Date : 2021-07-21 12:50 UTC (10 hours ago)
(HTM) web link (web.dev)
(TXT) w3m dump (web.dev)
| seaish wrote:
| `.map(x => x * x)`
|
| 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.
| RReverser wrote:
| 1) Oops, thanks for pointing out the mistake. Will fix in a few
| minutes. 2) The freaky thing is, I'm fairly sure I didn't even
| see or look at Rayon's official example in README when I came
| up with that example for my crate I only came up with it
| because I was _just_ working on root mean square errors in
| another side-project. That's hell of a coincidence.
| rough-sea wrote:
| Deno 1.12 supports wasm threads
| https://deno.com/blog/v1.12#atomics-and-sharedarraybuffer-sh...
| RReverser wrote:
| Nice! Just noticed the backlink from those release notes to the
| article as well.
| flohofwoe wrote:
| The bummer with WASM threads is the COOP/COEP headers requirement
| once it dawns on you that this only works if you have control
| over the web server configuration (to set the required response
| headers).
|
| 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 :/
| adkadskhj wrote:
| > Sometimes I don't understand what's going on in the heads of
| the people thinking this stuff up :/
|
| 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
| flohofwoe wrote:
| Well, "obviously" the web should have a mechanism in place
| that allows to request security sensitive features without
| having to poke around in the web server configuration,
| because in many cases this is "off limits" to the people who
| author the files to be hosted. How this is achieved, I don't
| really care, I only know that the current solution is half-
| baked.
|
| 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.
| brabel wrote:
| HTML meta headers used to be the solution to this kind of
| stuff, like the <meta charset="UTF-8"> tag for example
| (which contains information you can also provide in a HTTP
| header).
| pjmlp wrote:
| Good use of past tense, given that they aren't the
| solution any longer.
| RReverser wrote:
| The Github Pages situation is definitely unfortunate. We tried
| to contact them for couple of months to ask to add an option
| for COOP/COEP before the deprecation, but didn't have any luck
| with our contacts.
| nextaccountic wrote:
| You should still provide a fallback without sharedarraybuffers
| and atomics because safari doesn't provide them.
| alfg wrote:
| Ran into the same issue using Github Pages with an FFmpeg/Wasm
| project. Hoping they add support for these headers soon.
|
| I could use something like Netlify, but I like the convenience
| of the gh-pages branch and deployment.
| Santosh83 wrote:
| Well something as basic as CSP is also crippled without access
| to the server to set headers. And a lot of other stuff.
|
| The more relevant question here is why so few (if at all) web
| hosting solutions allow the user to configure custom server
| rules?
| jhgb wrote:
| > something as basic as CSP is also crippled without access
| to the server to set headers
|
| Why would communicating sequential processes be crippled by
| this?
| agency wrote:
| https://en.m.wikipedia.org/wiki/Content_Security_Policy
| jhgb wrote:
| Ah, I see. A different namespace.
| [deleted]
| flohofwoe wrote:
| TBH I wonder why response header requirements can't be set
| right in the meta tags in index.html. Would this be any
| different than having a provider-specific config file next to
| index.html from a security pov?
| Santosh83 wrote:
| Some of them can be, but not all. Some headers are needed
| before the content is loaded. With ubiquitous
| virtualisation these days, I don't see why hosting
| providers can't allow users more control over their server
| without compromising security.
| NoahKAndrews wrote:
| It's worth noting that Netlify is a much superior solution to
| GitHub pages that's just as easy to use, and it supports custom
| headers.
| flohofwoe wrote:
| That may be true, but it's up to the library users what
| hosting service they use. The people that decide to use (for
| instance) Github Pages shouldn't be left in the cold.
| petters wrote:
| Agreed, couldn't "I hereby relinquish my ability to bring
| other-origin content into this process without their opt-in" be
| a JS API call (one-way)?
|
| HTTP headers should not affect app functionality in this way.
| atom3 wrote:
| I've not try that but wouldn't the html meta tag work as well?
|
| Something like <head> <meta http-
| equiv="Cross-Origin-Embedder-Policy" content="require-corp" />
| <meta http-equiv="Cross-Origin-Opener-Policy" content="same-
| origin" /> ... </head>
| infogulch wrote:
| It seems the answer to the question "wouldn't this work" is
| "no", but I'd ask " _shouldn 't_ this work?" what's the
| problem with this being configured in a meta tag?
| Jasper_ wrote:
| No, http-equiv only supports a hard-coded whitelist of
| headers. https://html.spec.whatwg.org/multipage/semantics.htm
| l#pragma...
| flohofwoe wrote:
| Apparently not, but I haven't tried myself:
|
| https://stackoverflow.com/questions/67259043/can-coop-
| coep-h...
| dheera wrote:
| > COOP/COEP headers requirement
|
| 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.
| kristjansson wrote:
| This seems like a GitHub pages problem more than anything.
| Setting a header is a reasonable way to direct the client to
| behave a certain way, GH just doesn't want to set that yet?
| turnsout wrote:
| WebAssembly "threads" depend on SharedArrayBuffer, which is not
| available on Safari. Whatever your opinion of Apple or web
| feature adoption in Safari, this definitely puts a damper on
| things if you need to support mobile browsers.
| nextaccountic wrote:
| Web workers already exist and there's wasm threading libraries
| that target just web workers.
|
| 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.
| turnsout wrote:
| Yes, I've been using WebWorkers for 10 years. My note was
| intended to give folks a heads-up before they go rewriting
| their web app in C++ or Rust to take advantage of concurrency
| via SharedArrayBuffer.
| jbk wrote:
| Even on the beta of the next Safari?
| orbz wrote:
| According to https://caniuse.com/sharedarraybuffer it's
| default disabled on Safari due to spectre/meltdown, but can
| be enabled.
| paulgb wrote:
| In addition to SharedArrayBuffer, it looks like the atomics
| themselves are in-progress on Safari[1]. They don't work
| for me on Safari Technology Preview, FWIW.
|
| 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.
|
| [1] https://webassembly.org/roadmap/
| jlongster wrote:
| What doesn't work about them?
|
| 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).
| paulgb wrote:
| Ah, I should have clarified that I mean the assembly
| instructions for atomics, rather than the JavaScript API.
| I.e. the opcodes listed here: https://github.com/WebAssem
| bly/threads/blob/master/proposals...
| jlongster wrote:
| Oh right, that makes sense in the context of this thread
| :)
| RReverser wrote:
| > As far as I can tell, "threads" from a WebAssembly
| implementation's perspective is just the combination of
| SharedArrayBuffer and atomics;
|
| FWIW that's exactly what the linked post describes :)
| nightpool wrote:
| SharedArrayBuffer was disabled in Safari 11 due to Spectre
| and Meltdown vulnerabilities.
| https://bugs.webkit.org/show_bug.cgi?id=212069 re-enabled it
| behind a flag, and talks about making it public "Once cross-
| origin isolation is done". However, it links to
| https://bugs.webkit.org/show_bug.cgi?id=215407 as
| representing when cross-origin isolation is complete, which
| as I understand it hasn't seen any activity in the past year.
| turnsout wrote:
| As far as I can tell, it's not enabled in the beta, but looks
| like it's available on the Safari Technical Preview on the
| Mac behind a flag:
|
| https://developer.apple.com/safari/technology-
| preview/releas...
| lwansbrough wrote:
| I'm subscribed to all the current threads and issues relating to
| WebGPU multithreading. Very much looking forward to trying to put
| all this stuff together in order to enable multithreaded 3D
| rendering on the web.
|
| 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.
| billconan wrote:
| I'm not a native English speaker. The title got me confused.
|
| 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.
| clord wrote:
| substitute "posix threads" to see why it was written this way.
|
| 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++.
| TazeTSchnitzel wrote:
| Your suggested title makes me (native English speaker)
| interpret this the opposite of the way you intend.
|
| 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.
| jacob019 wrote:
| I am a native english speaker and I thought the same thing.
| devwastaken wrote:
| Async is another problem detailed that still plagues building
| wasm programs.
|
| 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. :)
|
| 1 https://emscripten.org/docs/porting/asyncify.html
| dnautics wrote:
| if you are looking for alternatives, you may want to try zig, I
| think async zig works in wasm, and I think you don't need to
| put stack winding hacks into the code.
| oconnor663 wrote:
| Not sure how much this helps, but in Rust "!" usually means
| "this name refers to a macro" and "?" usually means "if the
| value of this expression is an error, short-circuit the current
| function by returning that error." Usually when you're reading
| working code, you can ignore those two symbols and still get
| the meaning. (Those symbols also have some more advanced
| meanings for when you're dealing with generic/templated types,
| but those are pretty rare and unlikely to show up in examples.)
| incrudible wrote:
| Unpopular opinion: We would've been better off keeping web
| plugins and isolating those in a "click to play"-container rather
| than turning the web browser into an operating system.
| nobody0 wrote:
| This idea is not unpopular in hn I guess.
| paulgb wrote:
| When you say "we", do you mean web users or developers? As a
| user, I'm sure happier that I don't have to deal with needy
| plugin installers ("what do you mean you don't want Bonzi
| Buddy?").
| jacob019 wrote:
| While I share your nostalgia for the web of yore, it depends on
| the use case. The web browser is and has been an execution
| environment, long before WASM. Giving developers better low
| level tools unlocks more possibilities. I'm not really seeing
| the connection with applets/activex/flash. Sure you can do some
| things with WASM that you could do with those old tools, and
| much more.
| grishka wrote:
| Writing JavaScript and making sure my web UI gets laid out
| exactly as I intend makes me feel like I'm making a UI in a
| word processor that has a very advanced macro system -- but
| it's still a word processor at its core.
|
| 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.
| [deleted]
| afavour wrote:
| "isolation" in that context is a little misleading - Flash had
| countless security vulnerabilities that blew open any isolation
| you might have hoped to achieve.
| ducktective wrote:
| I mean what is the use of a "Web Browser" anyway? Couldn't each
| OS app communicate with its server over TCP/IP?
|
| 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...?
| gmueckl wrote:
| I think goes as far back as the dot com bubble when managers
| started to realize that it's easy to earn money by doing X,
| but on a website.
| vbezhenar wrote:
| Navigating to a web page is so much easier than installing an
| application. Even with modern operating systems like iOS.
| Despite the fact that web pages are getting more and more
| bloated, applications are like 10x bloated. And it's even
| officially supported. Modern Android application require
| embedding something like megabyte of various "compat"
| libraries. I don't know how iOS state of things is, but in
| the past Swift runtime was required to embed as well (you
| could avoid it with Objective C, but that's so out of
| fashion).
|
| 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.
| incrudible wrote:
| > Navigating to a web page is so much easier than
| installing an application.
|
| 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.
| saurik wrote:
| But the problem is that the premise of web falls apart if
| you have to install a separate app for every kind of
| content. I want to be able to have a hyperlink on my
| website to a TikTok video or an Instagram post and have
| people actually see it rather than go "ugh I have to
| install an app to see the content you are linking to". I
| want to be able to just click around the web without
| having to ever think about the boundaries between "apps".
| This is also why a lot of us hate authwalls: "oh god
| another account I need to set up"... it doesn't take much
| time to set up an account, but in a world where every
| single damned website would want an account you will
| never be done with it. The dual reasons then why you
| don't spend much time installing apps is because on the
| one side the web works well enough that people just link
| to stuff on the web and it works most of the time... and
| yet on the other side you also see people choose to
| centralize things into places that are easier to link
| stuff from, including apps people are more likely to have
| installed, which is a background force of centralization.
|
| 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.
| ducktective wrote:
| So essentially, it was a race between sand-boxing
| environments like JVM, .NET and browsers? I think there was
| a big potential for JVM to dominate this sector...
| ncmncm wrote:
| There were earnest early attempts at making Java and .NET
| the language to run webapps, that all failed. For
| reasons.
|
| 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.
| vbezhenar wrote:
| Sandbox for JVM was mostly an afterthought IMO. There
| were lot of vulnerabilities to escape sandbox, much more
| compared to browsers.
|
| But nail in the coffin IMO was Steve Jobs, who decided
| not to adopt nor Flash, nor JVM in mobile Safari.
| ducktective wrote:
| It's amazing how much our everyday experiences are
| resulted from decisions of few people or completely
| random coincidences.
| marcellus23 wrote:
| > I don't know how iOS state of things is, but in the past
| Swift runtime was required to embed as well (you could
| avoid it with Objective C, but that's so out of fashion).
|
| This is no longer true on iOS and hasn't been for at least
| a couple years.
| Santosh83 wrote:
| I think because the document centric web was already there,
| the infrastructure was there, and it was much more easier to
| extend it than to come up with a million NIH solutions. Each
| app can communicate over its own protocol but the web allows
| interoperability and that is its greatest strength IMO.
| nextaccountic wrote:
| The point of sandboxing and ease of deployment. I don't want
| to run a separate program for each random site I visit.
| staticassertion wrote:
| The problem is that the current state of operating systems is
| terrible. There's almost no isolation, tons of complexity, tons
| of attack surface, lock-in, etc.
|
| Browsers are a massive improvement as a platform for developing
| code, or at least they have the potential to be.
| andrewmcwatters wrote:
| It's almost like operating systems should keep up or
| something.
| TillE wrote:
| It's really unfortunate that multiple attempts at
| capability-based microkernels have basically failed to come
| to fruition.
|
| There _should_ be a FOSS OS with powerful OS-level security
| features, but it just hasn 't happened.
| nnamtr wrote:
| I always thought that's what Fuchsia is about?
| [deleted]
| TazeTSchnitzel wrote:
| I think every major OS kernel (Windows NT, Linux, Darwin)
| actually has optional sophisticated security capabilities
| these days. I think the problem is that it's really hard
| to make these work nicely with legacy software? The whole
| classic UNIX-ish model sort of falls apart.
| staticassertion wrote:
| I assume by capabilities they mean specifically a
| capabilities-based security model.
| colonwqbang wrote:
| Well, doesn't Linux have that? Maybe you could go into
| more detail about what you feel is missing today.
| staticassertion wrote:
| What linux calls capabilities is a misnomer that isn't
| particularly effective - it's sort of splitting root up
| into smaller pieces.
|
| 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.
| kllrnohj wrote:
| Only if you define operating systems as "Windows, MacOS, and
| desktop Linux"
|
| 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.
| staticassertion wrote:
| Yeah, mobile platforms are moderately better.
| pjmlp wrote:
| An opinion that I agree with, despite doing a lot of web
| development, but since Google basically wants to turn the Web
| into ChromeOS, with Microsoft's help, that is what it is.
___________________________________________________________________
(page generated 2021-07-21 23:00 UTC)