threads

Threads and Atomics in WebAssembly (by WebAssembly)

Stats

Basic threads repo stats
6
424
1.4
7 months ago

WebAssembly/threads is an open source project licensed under GNU General Public License v3.0 or later which is an OSI approved license.

Threads Alternatives

Similar projects and alternatives to threads

  • GitHub repo ic

    Internet Computer blockchain source: the client/replica software run by nodes

  • GitHub repo motoko-token

    The Token Package

  • GitHub repo Flutter

    Flutter makes it easy and fast to build beautiful apps for mobile and beyond.

  • GitHub repo Runtime

    .NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

  • GitHub repo Uno Platform

    Build Mobile, Desktop and WebAssembly apps with C# and XAML. Today. Open source and professionally supported.

  • GitHub repo WASI

    WebAssembly System Interface

  • GitHub repo webcontainer-core

  • GitHub repo schism

    A self-hosting Scheme to WebAssembly compiler

  • GitHub repo biwascheme

    Scheme interpreter written in JavaScript

  • GitHub repo gc

    Branch of the spec repo scoped to discussion of GC integration in WebAssembly

  • GitHub repo standards-positions

  • GitHub repo reference-types

    Proposal for adding basic reference types (anyref)

  • GitHub repo onload

  • GitHub repo exception-handling

    Proposal to add exception handling to WebAssembly

  • GitHub repo function-references

    Proposal for Typed Function References

NOTE: The number of mentions on this list indicates mentions on common posts. Hence, a higher number means a better threads alternative or higher similarity.

Posts

Posts where threads has been mentioned. We have used some of these posts to build our list of alternatives and similar projects - the last one was on 2021-06-03.
  • AMA: We are Akhi, Alexandra, Islam, and Dimitris from the DFINITY Execution team. Ask us anything about building the execution layer.
    reddit.com/r/dfinity | 2021-06-03
    Another point to add here is that the current wasm specification does not support threads although there is a proposal to add one. So I imagine that till the wasm specification includes it, we will continue to have only single threaded canisters.
  • WebContainers: Run Node.js natively in the browser
    news.ycombinator.com | 2021-05-20
  • Everything Old Is New Again: Binary Security of WebAssembly [pdf]
    news.ycombinator.com | 2021-05-01
    I explicitly stated I was talking about WASM being used in traditionally native process contexts - like in a serverless/microservices architecture. The first obvious step of someone offering that is to just import libc so existing code can migrate to it.

    You seem to be continually focusing exclusively on the current existing extremely limited WASM-in-a-browser usage.

    WASM's current limitations aren't intentional, it's because it's not finished & wasn't necessary for the MVP. In fact, it already has some of the things you are claiming it doesn't have - both threads & shared memory are available already in Chrome & Firefox's stable releases ( https://github.com/WebAssembly/threads/blob/master/proposals... & https://webassembly.org/roadmap/ ). Which means it also has accurate timers.

    WASM very intentionally allows the host to expose whatever feature set it wants. That's a very core design element. You can't just ignore that and focus on the ~nothing that the "spec" itself delivers & pretend that's by-design. WASM isn't a standalone runtime and isn't trying to be.

    news.ycombinator.com | 2021-05-01
    You're talking about some hypothetically fully featured WASM that has all kinds of attack surface it simply doesn't have today. It doesn't even have threads; nor accurate timers, nor shared memory; and those choices aren't by coincidence, they're by design to keep things safe (see e.g. https://github.com/WebAssembly/threads/issues/8).

    If indeed webassembly adds features that add attack surface, I sure hope (and fully expect) them to take things like spectre into consideration.

    As to SELinux: the issue with securing existing programs is that use use all kinds of existing features; it's quite hard to take away functionality that programs depend on. SELinux simply has a much harder and trickier task than WASM, which never supported almost everything SELinux seeks to control in the first place. It may well be that it's possible to have SELinux enforce WASM-or-greater restrictions and that it would then be "safer" due to other features, but that's a pretty hypothetical scenario - what software would even run in those circumstances?

    The comparison seems moot to me; apples to oranges. One is trying to KISS and be safe by simply not having complex features; the other is trying to deal with real, existing programs by restricting stuff they could access but don't need. Those are different use cases.

  • news.ycombinator.com | 2021-01-05
    There is of course the threads proposal [1], which works in chrome with a feature flag, but most runtimes don't support it yet.

    In general I have to agree that WASM needs more time. There are multiple quite crucial proposals in the pipeline (reference types, interface types, GC, threads, ...) which have all seen very slow progress.

    Overall I'm still bullish on the potential of WASM for universal deployment, but the slow pace is a bit concerning.

    [1] https://github.com/WebAssembly/threads

  • Do you think native machine code compiled languages like Rust should replace Bytecode compiled languages like Java, Kotlin, and C#?
    reddit.com/r/rust | 2020-12-25
    That said support is most likely somewhere on the map and there is even an ongoing proposal to add WASM threads (https://github.com/WebAssembly/threads/blob/master/proposals/threads/Overview.md) so it is more a matter of when we will be able to create a server from a WASM module not if.