Not directly related to this thread, but I was recently unpleasantly surprised how under-defined and undocumented is WASI.
I was looking into some detail of a WASI call and there is… basically nothing.
Also the latest version of the docs is called something like “snapshot3” or whatever. I thought “wait this is it? that’s the whole definition”? apparently it is.
edit: here. The actual latest definition is in "legacy/preview1". Yes that is the latest WASI definition.
What do the inputs mean? How should it behave in some extreme conditions? Eh YOLO who knows. All implementation dependent.
This document is literally all there is. That's it, that's the WASI definition.
Nobody is documenting anything because all that matters for people in this area is for existing C/C++/Rust code to run without modifications on WASM, which means whatever low level POSIX APIs they use is what WASI will support. A large number of software has been ported to run on WASM/WASI, and you can ask yourself how is that possible if WASI doesn't even have a formal API? Because the API is basically being reverse engineered.
We (Wasmer), and other community members, were already aware of this.
Because of that, we tried to be as detailed as possible about the system calls. We might to define them further, but hopefully the WASIX docs are a good start! https://wasix.org/docs/api-reference
As an implementer of WASI, I applaud this. Also, we are using wasi-testsuite and plan to contribute to it as Wizard finally has a full-time project for WASI.
I agree. I implemented a subset of WASI, and the best resource was an autogenerated C header with function signatures and very terse comments, buried in the WASI SDK repo.
WASM is a language independent byte code that runs in browsers, like “assembly but for browsers” that multiple languages can compile to instead of there only being javascript.
…but that ran in a browser sandbox, and people wanted to use it in containers, so they invented WASI, which lets WASM assembly code interact with the base system, sidestepping the container of the browser; but it needs a runtime on the host system (not a browser) to run.
Now this is WASIX which added more non standard extensions to WASI so that more programs can run on it.
We had an entire full stack cross platform runtime (browsers) to run our code in, but instead we now need to get a new set of “low level” runtimes to run the same code for, eg. containers?
Sounds a lot like java to me; byte code, runtime, “cross platform binaries”, write once, run anywhere…
How is this meaningfully different?
The only remarkable difference appears to be you can target it with existing c++ code?
Java is a language with a particular view of the world, and the JVM is a heavyweight runtime for executing that particular view of the world. The core idea of the JVM is great, and WASM executes that without assuming anything about your language, or requiring a great big tightly integrated second-banana-to-the-host-language's-stdlib system library, or anything else Java-y.
The great wheel continues to turn. If your wasm environment is a thin wrapper around the host you need to worry about the underlying system. So expect to see more and more abstraction or a break in portability. Similarly WASM assumes a lot about your language: imperative, statically typed, limited polymorphism, no GC (for now). It's not a good target for JS or Perl6 or Smalltalk or Common Lisp.
WASM reflects the usual capabilities of a hardware-based CPU. Just like your usual hardware CPU cannot run Common Lisp directly, neither can WASM.
JS, Perl, Python etc. all run well on widespread CPU architectures like ARM and x64. And that's why they will run well on WASM too given an appropriate runtime for that language.
To sum it up, WASM assumes nothing about a language - it's just a CPU, albeit a virtual one.
Obviously Church Turing tells us all substrates are the same in power. So when we talk about running well on X we mean something else.
WASM is not like any CPU in common use today. It's a stack machine with structured control flow and strongly typed pointers. The instruction sequence is a graph. Memory is not a flat address space.
I wouldn't call it a stack machine. Constraints requiring static stack depth is designed to be converted to SSA which then gets efficient register allocation
My experience with CPython (a while ago now) was that it ran like a dog on POWER, and that if you didn't account for the idiosyncrasies of the architecture in the interpreter's implementation, running "well" was a pipe dream. Considering WASM actively masks the underlying architecture, what evidence is there that other managed runtimes will naturally run well on WASM?
That's an interesting and open question. Especially the ability to JIT the code on the fly, so it could travel, say, Java -> WASM -> Hardware path. It seems that it's technically possible [0] but there will be dragons.
Let's hope that will never happen because it will lead to an imminent WASM death by making it opinionated.
I would also suggest to officially separate WASM from any notion of API. So that any working group anywhere in the world could design whatever API they want/need - but it would not wreck the purity of WASM as a result.
WASM GC is already shipped with Chrome. Flutter is already compiling to WASM on the web and can execute with Chrome and apparently Firefox now, using the "native" GC instead of shipping one with the Dart runtime: https://docs.flutter.dev/platform-integration/web/wasm
EDIT : to clarify it, both Chrome and Firefox (nightly) require feature flags to enable WASM GC as of writing.
Last I checked, the GC primitives in WASM are rather low level, and are more for building a GC system on top of, rather than relying on it to be your whole GC.
What a perfect seppuku. RIP WASM, thou was fun while thou lasted.
The only chance of survival is to declare WASM GC a heresy and to largely ignore it until it rots away like Intel iAPX 432 did. But considering the financial model of the current WASM development this plan may be unrealistic.
Why? You can still implement a WASM runtime with no GC, and so it's just additional functionality for where's its desirable. Additionally, the GC spec is low level and allows for pluggable GC, and better defines the WASM memory model.
@foota, WASM GC is a bad development because it's opinionated.
For example, the nice WASM <-> CPU bijective mapping of capabilities is going to be lost. WASM GC now turns the WASM into something completely different, something in the rank of Java, .NET, Flash, Node JS, or Elang.
For any GC to work, there must be a notion of a component model that defines the type system and the rules of type interactions. This is a complex topic by itself with myriads of decisions and compromises to make. This means that the end result won't suite everyone, if anyone at all.
This will lead to WASM GC stagnation - it will be there but nobody will be using it because no one wants to loose the ground and compatibility with real CPUs. There may be some users like Dart or Flutter with their niche opinionated situations, but it's a drop in the ocean.
As the time will pass, WASM GC will be gradually becoming a burden as it does not come for free - it requires maintenance, patches, security fixes. In the end, browser vendors may proclaim the WASM a new "Flash", "Java Applet", "ActiveX" that should be eliminated due to overdesigned complexity, too wide API surface, and associated security risks.
Rinse and repeat, there is nothing new under the sun.
Well there needs to be an alternative... A GC implemented in WASM isn't ideal because it doesn't let you walk the stack so you need to make a second software stack which is slow, and it also increases the binary size a lot
As much as the broader programming world is loving WASM as a barebones VM and sandbox, it ultimately was created to further the interests of the organizations championing it and their desires and it's clear that making it a complete JS stand-in is the direction it is heading. GC is only a question of time.
And this why WASM is so great. No opinions on a language, APIs, or anything; just pure execution. Well, WASI and WASIX are APIs but they are not strictly obligatory.
No it's not. If you want to know how it's meaningfully different - go look look high level overview of JVM and WASM - and if you still don't get it - then you're probably not the target audience for either and you should just be using whatever the tool stack it's targeting them.
A bus and a cargo truck are not the same just because they have similar wheel base/size and abstractly do the same thing.
To me WASM just seems like the JVM without special OOP instructions.
It never started out that way, but it certainly is ending up that way. Everything that made WASM stand out from the traditional bytecode VM is being patched back in through extensions like WASI and now WASIX.
I was originally excited for WASM because it started out as a fully sandboxed system. No I/O other than flat memory buffers, so no chance whatsoever of escaping its sandbox.
Now WASIX introduces networking, file system I/O, mutltithreading, forking, even TTY support. It's not as powerful as the JVM yet, but give it a few years and I'm sure you can use them interchangeably in a few years.
This reminds me of the old adage that the most secure computer is one that has never been, and can never connect to anything. It's also rather limited in its usefulness.
The limitations are what made WASM attractive to me. If I want a fast component to re-encode images, or to render a 3D scene, or to analyze and transform data, I don't want to have to set up a network namespace, alternate file system roots, and all the other annoying stuff that comes with sandboxing. WASM not being able to do or access anything you don't manually provide allows for quickly and easily hooking in executable code without the normal risks.
Add enough extensions to the runtime everyone uses and you end up with another JVM. The JVM is very good and so is the .NET runtime and any other bytecode runtime you can think of, but the distinctions start to fade as more features get tacked onto WASM.
You can use cargo trucks to transport people and buses to transport cargo - so they are interchangeable ?
"Special OOP instructions" - you mean like object model and garbage collection ?
WASI is aiming to run in the browser sandbox which means it's API interface has to be more sandboxable than POSIX. Implementing POSIX compatibility layers on top of it is going to be leaky.
If you cut out the seats, attach a trailer hook up, put up a sheet behind the driver, and lower the engine, then you've created a truck out of a bus. There was no reason to turn a bus into a cargo truck and the result isn't better than any existing cargo truck, but your transformation altered what the original vehicle is likely to be used for.
Removing the limitations that make WASM such a safe system to implement and replacing it with POSIX system calls is like ripping out the seats and replacing them with a trailer hook up. There's nothing wrong with being able to attach large trailers to your vehicle, but the type of vehicle you're converting may be better off without your alterations.
The JVM contains instructions such as instanceof and various ways to invoke a method that mirror the OOP approach of Java. Garbage collection instructions are also extensively used, of course, but they're not as OOP specific.
Unlike WASI, WASIX adds open()/read()/write()/close() to WASI. It also adds fork(), exec(), and wait(). With modern web APIs (such as the filesystem API) many of these can be added without any virtual implementations, but WASI and WASIX are also targetting other use cases. One use case being pushed by a lot of WASM companies is for WASM to replace Docker containers in a Kubernetes cluster, for example.
WASM won't be able to get any real level of adoption if you have to specifically write all your code to target it, which I think is what would happen if the sandbox is too restrictive.
If you can trivially move existing code to run in a WASM VM you get the benefits of isolation and a convenient artifact to move around for deployment and scheduling.
I think the history of successful platforms are ones that still supported the old way of doing things, while enabling a new and better way. Of course that comes with lots of tradeoffs that are often hard to stomach.
I agree that "WASM as a generic target platform" is the best way for WASM to gain popularity and actually get used.
However, that would make it end up as "Java but different". That's not a bad thing, there's absolutely nothing wrong with Java as a technological concept!
I see your point for how things are now, but the WASM roadmap and proposals do have several things on it that take it into territory that's closer to the JVM.
Yes, it is "JVM reimagined". It has very little with browsers, though.
IMO this is wrong direction.
Better direction is to move into browser. Add arch/wasm to linux kernel. Compile it to wasm. Compile systemd to wasm, glibc or musl, with docker in the end. Now you can run linux in your browser. You could run it before, but this way makes it as native to browser as possible. Probably will be very fast and suitable for work.
Now with docker ask people to compile their software to wasm. Now you can run postgres and kubernetes in your Chrome tab. All you need is some escape hatch for network ingress/egress which is not hard to implement.
May be implement virtio-gpu with webgpu and you can easily run full-fledged Gnome in your browser tab. Not hard to sync your disk to S3, so you can open this VM from any computer and run it locally.
Basically VM in your browser, cross-platform, cross-architectured.
I think you're basically correct. But wasm isn't tightly coupled with a single programming language, like Java did. Of course, other languages can target JVM too, but there's not much momentum there. With wasm, we have many different implementations written in many languages running in many different platforms. I think it's a good thing.
Those languages are very much designed around the JVM though. You
have Scala, but not eg: C++, because the JVM itself is much higher level than what many languages would want to target.
Arguably, JVM languages have much better tooling for them to be designed and interoperable (through Truffle and GraalVM) than WASM where everyone has to write a backend (or use LLVM which has its downsides).
These are all languages that were designed expressly to run on the JVM, whereas WASM aspires to support existing languages. I'm not familiar with JVM bytecode (and would love to hear from someone who is), but I'm guessing the JVM bytecode offers less in the way of low-level control over memory allocations and so on which would be required to compile C, C++, Rust, Go, etc programs with reasonable performance characteristics?
JVM bytecode assumes the GC allocates and frees memory, so no, you don't have direct access to memory... though the Java standard library does let you allocate bytes and manage those yourself[1], not sure if you would consider that "more control over memory allocations".
And does look superficially similar to WASM instructions. When WASM gets GC, I have trouble seeing what's fundamentally different between the two, to be honest... even something like (parts of) the Java stdlib will be available to WASM with the WASI API, making the difference too small to distinguish them into different categories IMO.
> though the Java standard library does let you allocate bytes and manage those yourself[1], not sure if you would consider that "more control over memory allocations".
That's interesting. So if you wanted to build a C compiler targeting the JVM, you would just request a big byteslice from the API and implement your own stack + heap on top of it (such that you never actually use the JVM GC)?
> And does look superficially similar to WASM instructions. When WASM gets GC, I have trouble seeing what's fundamentally different between the two, to be honest... even something like (parts of) the Java stdlib will be available to WASM with the WASI API, making the difference too small to distinguish them into different categories IMO.
It sounds like the fundamental distinction is that WASM will have both manual memory management APIs as well as GC APIs while Java will only have GC APIs.
I'm not really arguing that WASM was the first to target previously existing languages, I'm arguing that WASM has a reason to exist because (1) it's an extant project and (2) it solves for other requirements (e.g., streaming compilation) that weren't previously addressed. I could well be wrong, and if so I'd genuinely like to hear how CLR actually solves all of WASM's requirements (essentially how we should have just shoved CLR into browser engines and called it a day!).
I think we're always looking for the silver bullet that shall make computer software development easy.
The following technologies were all silver bullets:
* ActiveX, COM Object model, XPCOM
* Unified Modeling Language (UML)
* Extensible Markup Language (XML)
* Computer-aided software engineering (CASE)
* Java Virtual Machine
* Ionic, React Native, Qt, Gtk, Flutter
Something tells me that the problem is bigger than anyone can chew and the abstraction solution is sometimes more complicated than the underlying thing being abstracted.
I think WASI and WASIX is an EXTREMELY important API for the future of computing. It's a chance to create a superior operating system runtime interface.
> I think WASI and WASIX is an EXTREMELY important API for the future of computing. It's a chance to create a superior operating system runtime interface.
Superior operating system runtime interface and POSIX don't rhyme. The fossilization of POSIX on Unix-like systems, endlessly piling stuff on top of that creaky foundation is probably the single biggest issue holding back the future of computing.
WASIX is probably a pragmatic design if you want to run your existing Unix programs on top of WASM. If anything, it's for the past of computing.
What the system call ABI that my modern operating system ought to have is not one that thinks fork() as a fundamental primitive is fit for purpose on modern computers [1], for starters. Mind you, my grievances on the design and typical implementation of Unix-like operating systems go far beyond fork(), but it's as good an entry point as any for this discussion.
I encourage you to read the design documents for the Fuchsia operating system, especially those for the Zircon kernel [2] for a fresh, legacy-free take on a system call interface.
i coded the WASIX fork syscall, so I understand all this (f.y.i. I much prefer rust to C as its got a much better designed threading system).
what you must realize is that one does not have to use a syscall if they don't like it in (e.g. just use rust to code your app and it will never call the fork syscall)... but taking that choice away from others who want to use it is unfair as its denying them access to the WASM ecosystem (e.g. bash)
It looks like one can easily call fork() in an unsafe block from Rust [1], assuming it's provided by the target's libc.
OpenVMS for example does not provide fork(). What it does provide is vfork() by doing some internal book-keeping within the C run-time library and delaying the actual child process creation until exec() is called [2].
The POSIX specification eventually standardized posix_spawn() [3] as a partial alternative for fork() due to its numerous issues, some of which are detailed in the rationale section of its specification. Sadly, it appears its usage is not as widespread as it could be.
I'm not blaming the WASIX project for providing POSIX semantics since running POSIX-compliant programs is an explicit design goal. What I do wish is that more people realize that POSIX isn't the pinnacle of operating system interface engineering or some sort of holy scripture that shall not be questioned. It's 1970s legacy from long defunct hardware and obsolete software (think PDP-11 and Version 7 Unix) that was written down as a specification in the 1980s.
Compiling native application to operating systems that Wasmer is compiled for including the browser and have the code seamlessly work in all of them, I think that's really promising.
JVM forces you to write in Java or a JVM targeted language but WASM lets you compile any language that creates a WASM backend.
> JVM forces you to write in Java or a JVM targeted language
And this
> WASM lets you compile any language that creates a WASM backend
Are basically the same thing.
There’s no fundamental reason that all these languages couldn’t target JVM byte code instead of WASM. It never happened, not nearly as much as WASM backends are, but it could’ve.
I have, albeit not terribly extensively. I will readily agree that there are cogent arguments for replacement that pass the Chesterton's Fence test. But I also see quite a lot of "That's too complicated to bother understanding, I'll just do my own thing"
> Compiling native application to operating systems that Wasmer is compiled for including the browser and have the code seamlessly work in all of them.
And thanks to stuff like this, contemporary browsers are now so complicated that
they only run on the top handful of platforms. So how is it progress?
I bet JVM runs more places than modern browsers.
> VM forces you to write in Java or a JVM targeted language but WASM lets you compile any language that creates a WASM backend.
WASM forces you to write in something that has a WASM backend just like JVM forces you to write in something that
has a JVM backend. It's just the same all over again. And again.
The JVM expects that languages will conform to its bytecode specification, which is designed first and foremost for Java. WASM's bytecode specification is designed to support the existing ecosystem of languages including Rust, C, C++, Go, etc which can't easily target the JVM. Relatedly, the body which manages the JVM specification is comprised of major Java vendors and users; they don't represent developers of other languages even if the JVM nominally supports a few of them.
>WASM's bytecode specification is designed to support the existing ecosystem of languages including Rust, C, C++, Go, etc which can't easily target the JVM
Microsoft's .NET allowed you to compile C++ to pure CIL (.NET's bytecode) and run it inside a VM since the early 2000's. It wasn't very popular so it was deprecated.
People compare WASM to JVM, but to me it looks like a more lightweight reinvention of Microsoft's CLR (Common Language Runtime) which was designed to support multiple languages (C#, C++, VB) from day 1.
Sure, .NET is technically cross-platform, but that's a relatively recent development, and WASM has runtimes that let it run in most environments, even microcontrollers.
Also, looks like C++/CLI had conflicting syntax with standard C++, so it might not have worked on some applications without some patches.
So here's the thing, CLR is still here (now called CoreCLR as of the move to .NET Core), how does it differ technically from WASM/WASI, and why aren't we using it instead?
I should note I haven't spent much time studying either of them.
WASI (or rather POSIX) was never a good fit for the browser application model though. Emscripten did a pretty good job providing an incomplete "POSIX emulation layer" to get things rolling, but for WASM that needs to run in the browser it's better to go with Emscripten's web API mappings.
I think it's more about streamlining application deployments and removing the containerization hurdle...The dream seems to be a universal byte-code (WASM) vm that would open the door so that Python, Node, Java 58LTS, Rust, C or freaky Lua scripts could run on the same runtime -- easily -- without container wrappers that each have to be secured (patches) and with a startup penalty.
I think server side WASM has the potential to be the next thing after containers.
And yes, lots of echoes of Java's "write once run anywhere" but as lots of people have pointed out, wasm is language agnostic, and many languages have support for it.
Since I've been web applications and distributed systems, the evolution has been something like this.
1. Copy files around, into the web or application servers directory. This was simple but isolation, repeatability and testability was hard. The application dependencies were directly tied to the host, so you had to be very careful about your upgrades breaking applications. The lack of isolation is not suitable for multi-tenant environments for security and capacity planning reasons. It's pretty hard to run multiple-applications (1)
2. Things like bundler, and other language specific tools that let you bundle your application dependencies together. Avoids some of the host OS related upgrade issues, but again, no real isolation.
3. VMs. The whole cloud industry started on this. You get true isolation of your whole application at the cost of complexity and weight. Scheduling new VMs is not a fast process because you're copying around or at least booting a whole OS. You still have to manage OS images. There is also generally a tax on memory that you have to pay, so you waste some resources with VMs to get the isolation. Amazon invested in Nitro to avoid paying a lot of this tax.
4. Containers. Lighter than VMs, good enough isolation in a lot of cases, especially inside of an organization. Lower tax than VMs. More testable. But containers are still fairly heavy, startup time can be slowish. So you have some limitations on how fast you can scale up and down in response to load. Also isolation isn't good enough for some workloads. So we see things like firecracker VMs being used to improve isolation.
5. Wasm on the server side. Much lighter than containers. Less memory overhead, way less startup time. Probably faster startup time than even firecracker. So for lambda like workloads you could could have a lot better cold start latency. You probably have good enough isolation that you don't need to resort to things like firecracker to isolate customer workloads. Because of the fast startup time you could probably pack your long tail of workloads even tighter to get better effective utilization out of your server infrastructure.
(1)
In the early 00s I worked at a place where we wrote our own simple process supervisor and used some tricks with LD_LIBRARY_PATH to let us bundle all application dependencies with the application. So you could run multiple application that needed different libraries on the same host, and upgrade your host without as much worry about host OS library changes breaking our applications. It was a kind of proto-container, without all the other isolation cgroups give you.
This seems pretty inherently difficult to port or to run safely. Things like fuetxes will only work directly on Linux and OpenBSD, for example. From what I recall, OSX has some undocumented futex-like-but-not-quite ulock, and FreeBSD has yet another incompatible tool.
Fork is not a windows-native primitive, and while cygwin may have implemented emulation, the performance sucks. Pthreads is in a similar situation.
So, given that this will mainly target linux well, I'm not sure what advantages it brings over native code. It mostly feels like native code with extra steps.
WTF locks under C++ and Parking Lot under rust are great low level futex-esque cross-platform abstractions/implementations. They originate from the WebKit codebase (unless it was Blink but I think they predate the fork).
They run under Windows, Linux, the various BSDs, and macOS.
> We want to welcome as many developers and companies joining and participating in WASIX. This is a project that aims to be governed by many entities, not just one.
> Wazero, Zig, and AssemblyScript could be great additions to the governance team, but any others will be more than welcome. As long as you want to move WASIX forward you will be welcome to chime in and participate in its progress.
What exactly is your point? Wasmer is doing some pretty good work on top of WASM... There are some pretty neat stuff they have developed, mostly open source as far as I know... why should anyone care who is "moving away" from them?
It's worse than that in reality. The runtime is supported by the great wasmer employees. The rest of wasmer is in a constant state of bullshitting themselves and the public. Look what year they started, how many years it has been since then, how many products they have launched since, how many weird and sociopathic and narcissistic displays the company has on public record.
Also, of course you can ask other former employees and they'd tell you the same: work culture is toxic. In fact the list of ex-employees is huge because of this... I'm thankful I quit fast enough. If any throwaway account replies to me, you'd know who it is.
Excited for threads, sockets, futexes, but not excited for fork, signals and setjmp. They didn't include POSIX stuff like shared memory, select(2), unix sockets, and had to draw a line somewhere. Why include error-prone cruft?
* classical shared memory (mapped into the main address space) is very hard to do in the context of Webassembly, especially in a performant way. Not impossible, but complicated. It would be valuable to add, but there are different approaches as well (like sharing additional Webassembly-level memories between instances, for example)
* WASI already has a concept similar to select
* unix sockets would be a pretty straight-forward addition
> Why include error-prone cruft?
A big goal here is to make existing software compile to Webassembly, with only a relatively small amount of changes.
For writing new software the direction of WASI (going towards the fine-grained capability model) is a very valid approach. But that won't get you compatibility with pretty much all software in existence.
Plain fork (as opposed to vfork) isn’t really error-prone, it’s arguably less error-prone than threads. (It forces bad resource accounting, like most CoW mechanisms, but that’s an orthogonal issue.) Signals and setjmp... have their problems, admittedly, but on a restricted VM like WASM are AFAICT unimplementable on top of other things. So if you want unwinding, you’ve got to have an equivalent to setjmp (or throw / catch) if you want asynchronous interrupts, you’ve got to have an equivalent to signals.
> So if you want unwinding, you’ve got to have an equivalent to setjmp (or throw / catch)
Unwinding is a somewhat cleaner interface than setjmp/longjmp, and it's a useful primitive in its own right, especially if you can attach a notion of a stack trace to the unwind primitive. At a low-level language primitive level, unwind can be seen essentially as a combination of a mechanism to have two distinct exit points from a function call (the normal and exceptional return addresses) and an intrinsic that causes the function to return via its exceptional return address instead of the normal return address.
> if you want asynchronous interrupts, you’ve got to have an equivalent to signals.
... not really. There's a few different kind of signals. Synchronous processor signals (e.g., SIGSEGV, SIGFPE) could be supported via something akin to unwind rather than signal handlers (and this is essentially how they work on Windows). The asynchronous events can instead be supported by basically having some primitive notion of an event loop, dropping those signals as events in the event loop. Signals already interoperate pretty sketchily with event loops, and many signal handlers for asynchronous events already tend to boil down to "just dump this as an event in the event loop", so you're left with a pretty sketchy work around to do what you actually wanted to do.
Interfaces like fork and POSIX signals are pretty notorious for being generally wrong ways to do what you actually wanted to do; if you're making a new OS ABI, there's absolutely no reason to include them, especially because they can be hard to emulate on some OSes, e.g., Windows or Fuchsia (which lacks POSIX signals altogether).
>> So if you want unwinding, you’ve got to have an equivalent to setjmp (or throw / catch)
> Unwinding is a somewhat cleaner interface than setjmp/longjmp, and it's a useful primitive in its own right
I think the distinction is becoming subtle enough that we need to define our terms here. I’d distinguish three mutually interexpressible (is that a word?) systems:
(1) Marks (for lack of a better term): C. There’s an object that designates an activation (jmp_buf) that you can ask for (setjmp), unwind to (longjmp), and must not let escape. Upside: disjoint error filters do not require cross-ABI cooperation. Downside: finalizers do.
(2) Panics: Forth ’94, Lua, Go. There is a singular dynamically scoped recovery point where you can unwind and pass some data, which it will be able to rethrow further if it wishes. Upside: finalizers do not require cross-ABI cooperation (unless you hardwire backtraces). Downside: disjoint error filters do.
(3) Exceptions: C++, Java, arguably Common Lisp THROW/CATCH as a degenerate (no-subtyping) case. There is a single system of errors mandated by the platform (or language, as the case may be) and a stack of handlers of two types: catch, associated with an error type, which stops propagation of its subtypes and runs user code; finally, not associated with anything, which suspends propagation of anything, runs user code, then resumes propagation. Upside: implements the semantics of C++ directly in the system. Downside: anybody who wants anything else will have to fight the system.
(4) Filters: Win32 SEH (both old- and new-style), Itanium ABI (IIUC). Basically (3) but a catch-type handler is matched by running user code, either in the middle of an unwind (simpler) or before it (does not destroy stack traces). Upside: you get some degree of language interop compared to (3). Downside: the interop is still anemic compared to the complexity.
(4a) Declarative (4): Win32 SEH (new-style), Itanium ABI. Upside: security (?), speed (?). Downside: uninvolved code (C, JIT) needs to get involved; better get your stack maps right the first time (*cough* Itanium’s 30% size overhead *cough*).
To me, only (1) and (2) sound like real options on the VM level. If what you mean by “unwinding” instead of longjmp is (2) instead of (1), I’d say the advantages and disadvantages here are basically mirror images of one another and so far I can’t see a reason to prefer either. If you mean to replace (1) with something else, please elaborate—my options (3) and (4) are somewhat fuzzy and possibly nonexhaustive.
> especially if you can attach a notion of a stack trace to the unwind primitive.
As a registered Conditionist[1,2] who thinks all systems of non-resumable exceptions suck, I take exception to this (pun not intended). More directly, if you’re going to turn SIGFPE or SIGILL or SIGTRAP into exceptions, the debugger / crash recorder / etc. needs a stack trace available on an ununwound stack, and those tools are the only consumers of a stack trace in non-insane production code anyway.
See also the part about the stack map format in (4a).
So far, then, I feel that the stack trace tie-in is just not a good idea.
> At a low-level language primitive level, unwind can be seen [as] a mechanism to have [...] normal and exceptional return addresses[.]
I’m unaware of double-barrelled CPS being used as anything but a theoretical tool, but it would be interesting to see. [This is the part that made me think you meant (2) by “unwinding”, as it fits this model most naturally.]
>> if you want asynchronous interrupts, you’ve got to have an equivalent to signals.
> ... not really. There's a few different kind of signals. Synchronous processor signals (e.g., SIGSEGV, SIGFPE) could be supported via something akin to unwind rather than signal handlers (and this is essentially how they work on Windows).
Which is why I said “asynchronous” :) (in part as a reference to VMS / NT APCs). But OK, let’s have a digression: I agree that SEH is better than POSIX signals for synchronous processor traps, with two caveats:
- Whatever you replace a SIGILL handler with must be able to resume instead of unwinding, as the use case might be instruction or syscall emulation (SEH can do this, but your proposal doesn’t mention it);
- Whatever you replace a SIGSEGV handler with must also be able to resume and will probably find the memory location more interesting than the call stack (this is a problem with POSIX signals[3] that Linux solves with userfaultfd, and also a problem with SEH which Windows solves with an inferior hack[4]).
(End of digression.)
> The asynchronous events can instead be supported by basically having some primitive notion of an event loop, dropping those signals as events in the event loop.
I don’t expect I want to live in your proposed world—in an event loop, the flow controls you—but I probably want to see this world in more detail first.
Your mental model for async notifications also seems to be an I/O-bound program that wants to have the environment notify it about I/O. So had mine been—and then I wrote a CPU emulator, which is by necessity CPU-bound and cannot (non-hackily) afford to check for events with a syscall but still wants to hear about them, and suddenly SIGIO was looking mightily attractive.
This is niche. It is also solvable by having a second thread run select() and set the same flag my SIGIO handler currently uses and the emulation loop polls. A case where you wanted to gracefully terminate a thread, though (a case that I have admittedly not yet encountered, and that is even more niche), would require nothing less than an actual signal.
Again, niche. I’m not at all advocating for using signals everywhere POSIX does. But it’s not hard to think of cases where nothing will do but a notification that can actually interrupt your instructions and not just system calls. Maybe such cases are too obscure to handle (Java certainly seems unhappy with asynchronous thread termination), but “YAGNI signals” is a different argument from “signals evil”.
> Signals already interoperate pretty sketchily with event loops
AFAICS this is a problem of Unix getting select() and threads too late and the retrofit being subpar, not an inherent flaw. (And once again, I entirely agree that most POSIX signals should be turned into other kinds of notifications... It’s just that not all of them can.)
> Interfaces like fork and POSIX signals are pretty notorious for being generally wrong ways to do what you actually wanted to do [...].
Signals, see above. My argument about fork was very different: I don’t like it; I just don’t think it‘s guilty of GGP‘s specific charge of being error-prone—certainly not more so than shared-memory concurrency.
I think this may become the basis of an operating environment where you do not have to concentrate on "how to run" something. Instead, you get straight to the job of deciding "what to run" so you can reap the benefits in no time without all the devops and SaaS drama.
The closest contemporary thing is fly.io, but recently they became less strategic and more opinionated. Another attempt is sandstorm.io but it was abandoned by the original authors. So... maybe WASM and the initiatives like WASIX will give it to us?
By comparing to fly and sandstorm it sounds more like you're looking to solve the application hosting problem. How is that a problem solved by wasm? It's just a bytecode format and runtime, it doesn't deploy servers and load balancers. The only thing I can think of is that users build wasm binaries/containers and don't care whether the hoster uses x86 or ARM or RISC-V.
Exactly what you said, plus one more important opportunity (for the distant future): by being architecture-agnostic, the images of running WASM processes can freely travel between the nodes of a cluster, thus providing remote "exec", "fork" and roll-over capabilities. This can transform the way we create distributed software; instead of remote APIs, "queues", "buses" and "workers" we will be able to use the very same primitives we already use for in-proc and inter-proc coordination. So, the whole service like YouTube with transcoders and everything can literally be represented by just one or several executable files in a folder.
The biggest issue for cloud hosting/self hosting is sandboxing arbitrary hostile code. This almost always requires expensive KVM-based hardware accelerated virtual machines. AWS firecracker is the same shit as hardware accelerated VirtualBox, just heavily stripped down to allow for rapid booting. WASM comes from the CloudFlare functions/V8 ideology where a language sandbox is sufficiently locked down, such that you don't need heavy operating system level virtualization.
This way if one application gets compromised, it won't result in the entire physical server being subverted.
With a sufficiently complete environment like wasix, you don't even need the rest of the OS or even a kernel. A filesystem and a networking stack is all you need. Just load a unikernel from network boot and you are good to go.
As a long-time Nix-er, who was into Docker before anyone know what it was, and was committing to Kube pre-1.0, I just kinda giggle. It's all just shuffling puzzle pieces around. Whether you're compiling your Rust to x86_64-linux and shoving it in a container, or compiling it to WASI and shoving it in some runtime... there's still gonna be some horrifying bash script orchestrating it. Because there always is.
There's still going to be someone running Kubernetes, or provisioning VMs.
> where you do not have to concentrate on "how to run" something.
Sounds nice, been hearing this pitch for a long, long time. I really don't mean to be harsh, but it just sounds naive at this point.
Looks like Sandstorm still has the original founders on the FOSS project they now are, just not as a company. Both co-founders working for Cloudflare now:
Ideas from Sandstorm also live on in Cloudflare's Durable Objects:
> We don't have any current plans, but... I was the co-founder of Sandstorm.io before going to Cloudflare, and Durable Objects are very much inspired by parts of Sandstorm's design. So yeah, I've absolutely thought about it. ;)
The about page is very not updated, FWIW. I started a PR and then did not finish it. About every other week someone looks at it and gleans incorrect insight from it, so I really should finish that PR...
Most contributions presently come from outside the original Sandstorm team, but some significant features and refactors have come out since the company shut down from former employees too.
No, Sandstorm is not owned by Cloudflare. Cloudflare hired most of the team (myself included) but the company remained independent. Sandstorm the company dissolved last year. The open source project remains alive via the Sandstorm Community on Open Collective[0], but admittedly there has been little activity lately.
Sorry, I was being obtuse in that. CF now employs enough people that think "Standstorm" that it will eventually and perhaps does now support all the machinery necessary to implement Standstorm on CF.
There are a lot of people betting on WASM as a successor to linux containers for many use cases. Sockets and threads have been the main barriers IMHO to that happening.
One exciting advantage of WASM over containers is that it can run across different processor architectures and operating systems (the proprietary distribution of Docker runs on Mac but it does so by running a linux VM and containers not built for amd64 are noticeably slower).
How do they get networking and sockets working in the browser? As far as I know, no browsers allow raw network access. Some apps can get around this by using things like a websocket proxy, but this relies on routing your network traffic through a third party. It'd be great to see this solved and to let users host ephemeral network servers from their browsers.
So could one use this to run a fully socket capable Jupyter notebook? There are some infosec dashboards I would like to build, but not having the ability to actually run socket capable code killed the interesting aspect of doing it in the browser.
You can emulate a networking layer in the browser for different workloads to talk to each other, think an http server and client.
Of course the browser can't offer an actual networking stack by itself, but you can augment that by proxying traffic through a server over Websockets/WebRTC.
The only other equivalent API in broad use today that I'm aware of would be the Kernel32.dll subset of Win32 [1]. Not that it's perfect (so much accumulated cruft) or what I would call modern (still has a lot of ambient authority baked-in) by any means, but the important parts are mostly handle-based (unlike PID-based POSIX process management functions for example).
I happen to like the design of the syscall layer of Fuchsia's Zircon kernel [2], but it's not a full substitute for POSIX (notably, file and network I/O are built as userspace features of top of IPC channels, they are not kernel concepts).
I do not see a problem in that. You can always restrict the capability by not exporting a particular API function, or just by returning ENOPERM. It's the job of an operating environment to decide which permissions are available.
> As an example, we have created wasmer-web , which basically showcases that any WASIX program published to Wasmer (including those with threads and forking!) works also with Wasmer running on the browser.
I am curious about the browser compatibility layer.
Does it support networking? (And if so, is it using a proxy to connect to the internet or is it using a virtualized network layer that stays in the browser?)
How is fork implemented? (Asyncify all the code?)
I was looking at the Github org page (https://github.com/wasix-org), but I can't figure out where this stuff is.
I don't necessarily disagree, but implementing these things in your custom runtime is easy. I am more interested in how they achieved them in the more constrained browser environment.
its only nonsense from ones perspective... from another perspective it makes a lot of sense - if one wants to create a fully sandboxed browser terminal (benefits of which are huge). then compiling bash to WASM goes a long way as who wants to rewrite all that terminal code anyway?
now I know its hard to imagine someone other than your personal boogeyman contributing value to the open source world, but there is a real need for me to keep my coding skills up to scratch and it just so happens that `wasmer.io` are the coolest kids in WASM town right now, so I'll share my spare time with them thanks.
wasmer has a well-documented history of malicious behavior, they are very clearly not the coolest kids in WASM town, and very clearly not who you want to be aligning yourself with, but of course do whatever you like :shrug:
I'm wondering about platform limitations. A web browser doesn't actually let you listen on an arbitrary socket, so how does that work?
The supposed specification is more of an API reference and I don't really trust it to tell the developer what you can really do that works well on all platforms. It doesn't document platform-specific limitations, but I don't see it documented anywhere else either.
I also wonder about copying Unix semantics for fork and exec in a supposedly platform-independent spec. It seems like that won't work equally well everywhere.
Easy as 1-2-3. 'sock_listen' will return ENOPERM or something like that. The app can then decide by itself what to do - either bail out with an error message or continue to work with a somewhat restricted functionality.
“WASIX calls can be stubbed out in a browser” isn’t really living up to the promise of “running seamlessly in a browser.” That’s closer to “not working” than “working.”
More like "There is no browser I/O port corresponding to your desired WASIX call". ISA compatibility and I/O compatibility do not imply each other. As demonstrated countless times during the early days of the PC.
Why is it that when a new technology comes along for executing code, the first thing people do is say "this is great, but it would be awesome if it ran my 40 year old code without modification"?
The whole point of WASM was to provide fine grained capability based security in a portable environment. This made it safer than previous sandboxes, specifically because your code couldn't just open a random file in the host environment.
I think this is a very bad idea, and should be rejected. If not... we'll just take another 10 years until capabilities show up again, continuing the Sisyphean cycle.
* WASIX does not allow one to open a random file in the host environment, in fact WASIX changed absolutely nothing in file system ABI's at all from preview1 - it just added other extensions.
* WASIX has not removed the capabilities model and instead extended it to support Berkley sockets - i.e. there are capabilities defined for the new socket operations.
* WASIX is fully sandboxed, meaning the network is completely virtual and can be restricted as much as one likes
Worth remembering: Wasm on browsers is sandboxed by origin and can't do anything the JS cannot already do.
However, Wasm on computers with a full set of syscalls available is isomorphic to native code. Worse, because programs in C/C++ and other unsafe languages can compile to Wasm, any security bugs in those codebases will be present when compiled to Wasm. Wasm programs can still have buffer overflows, use-after-frees, and all the other fun memory safety issues; threads will add data races and memory ordering bugs to the mix.
The only benefit of Wasm in this space seems to be that you don't have to recompile your programs for a new architecture - kind of like a lower-level Java. But as soon as your program needs to interact with OS features or existing native libraries, this benefit is going to go out the window...
You are right about mostly everything except all the flaws of C/C++ making it into Wasm. Wasm still has CFI (Control Flow Integrity) and if you don't take the address of a stack variable, no C stack entry will be made, so much of the stack is invisible to user code (C/C++ code).
You can still corrupt memory, you can't implement ROP or subvert control flow in a non data-dependent way.
WASI has been in Preview1 for a couple of years now, indeed. However, Preview2 is well underway and the initial implementation is scheduled to land in wasmtime this June.
without these we can't compile our favorite apps in our favorite languages
lets help get these into preview2 so that WASIX is not needed anymore but until then the community needs an interim solution that has long term support - that is WASIX's complimentary goal.
lets reflect on this - if this was done as pull requests to `preview1` then would it have been accepted?... it would have received rejection comments around even the idea of these particular POSIX compatible syscalls.
WASIX should be seen as a preview 1.5 rather than something new, just extensions to WASI that add the missing bits that are badly needed today to actual compile useful apps from various code bases.
at a minimum this is an interim solution so that app developers can just start compiling their code bases into WASM and we can all get moving forward together - no one wants a fork here.
of course the WASI maintainers are reading all this and hopefully this will be a wake up call to add these missing syscalls as a priority also into preview2 so everyone benefits - then WASIX can die and its purpose is served... but until then WASIX will get long term support so the community can proceed literally today onwards.
In your view, what would it take to get the not-in-good-standing issue resolved?
What do you get out of shitposting Wasmer when they announce an initiative they are excited about? (I'm mostly trying to understand your psychology, not whether or if you have some kind of competing financial interest)
> In your view, what would it take to get the not-in-good-standing issue resolved?
probably the most effective way would be for the organization to release a statement abdicating their previous controversial positions, and for the CEO to resign
Yeah, I read all that. I still don't understand why/how the lawyers went ahead with the trademark process before the engagement letter was signed.
Like, I want to believe you, it just seems weird of lawyers to do the thing without the i's dotted and t's crossed. I can see software devs totally barging ahead, but lawyers, less so.
I was looking into some detail of a WASI call and there is… basically nothing.
Also the latest version of the docs is called something like “snapshot3” or whatever. I thought “wait this is it? that’s the whole definition”? apparently it is.
edit: here. The actual latest definition is in "legacy/preview1". Yes that is the latest WASI definition.
https://github.com/WebAssembly/WASI/blob/main/legacy/preview...
What do the inputs mean? How should it behave in some extreme conditions? Eh YOLO who knows. All implementation dependent. This document is literally all there is. That's it, that's the WASI definition.