[ruby-core:106994] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[ruby-core:106994] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[katei (Yuta Saito)]

Issue #18462 has been reported by katei (Yuta Saito).

----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462

* Author: katei (Yuta Saito)
* Status: Open
* Priority: Normal
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/

[ruby-core:107118] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[mame (Yusuke Endoh)]

Issue #18462 has been updated by mame (Yusuke Endoh).


At the previous dev-meeting, @katei elaborated this proposal and implementation approach himself. The patch is still being checked in detail by @nobu, but we agreed that it looks great.

Because WASI is actively being developed, we will need to keep up with their changes and feature additions. We need a maintainer of WASI platform. @ko1 and I recommend him as a committer and a platform maintainer for WASI in #18488.

This will be a big new feature for Ruby 3.2. @matz Do you accept this proposal?

----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462#change-95963

* Author: katei (Yuta Saito)
* Status: Open
* Priority: Normal
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/

[ruby-core:107136] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[matz (Yukihiro Matsumoto)]

Issue #18462 has been updated by matz (Yukihiro Matsumoto).


Accepted.

Matz.


----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462#change-95983

* Author: katei (Yuta Saito)
* Status: Open
* Priority: Normal
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/

[ruby-core:107399] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[jez (Jake Zimmerman)]

Issue #18462 has been updated by jez (Jake Zimmerman).


katei (Yuta Saito) wrote:
> For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

@katei do you have a link showing how this can already be accomplished with Emscripten? I've tried doing this before, but was not able to get it to work (I can't even remember what went wrong).

In any case, very excited to see this work!

----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462#change-96301

* Author: katei (Yuta Saito)
* Status: Open
* Priority: Normal
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/

[ruby-core:107406] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[mame (Yusuke Endoh)]

Issue #18462 has been updated by mame (Yusuke Endoh).


Hi @jez

Here you are: https://github.com/mame/emruby/

In short, please setup emsdk and then try `./configure --host wasm32-unknown-emscripten --with-static-linked-ext --with-ext=(an extension names that you want to statically link) optflags=-Os debugflags=-g0 CC=emcc LD=emcc AR=emar RANLIB=emranlib cflags="-s ASYNCIFY_STACK_SIZE=65535" && make`. Feel free to ask me if you have a question.

----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462#change-96306

* Author: katei (Yuta Saito)
* Status: Open
* Priority: Normal
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/

[ruby-core:107408] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[jez (Jake Zimmerman)]

Issue #18462 has been updated by jez (Jake Zimmerman).


mame (Yusuke Endoh) wrote in #note-4:
> Feel free to ask me if you have a question.

Wow, thanks for putting this together! I did in fact have a question, but I figure we can move the conversation somewhere else to keep this Ruby ticket on topic (discussing the WASI support).

→ https://github.com/mame/emruby/issues/6

----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462#change-96307

* Author: katei (Yuta Saito)
* Status: Open
* Priority: Normal
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/

[ruby-core:108048] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[mame (Yusuke Endoh)]

Issue #18462 has been updated by mame (Yusuke Endoh).


Just for record: https://github.com/ruby/ruby/pull/5702

----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462#change-97010

* Author: katei (Yuta Saito)
* Status: Open
* Priority: Normal
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/

[ruby-core:110435] [Ruby master Feature#18462] Proposal to merge WASI based WebAssembly support

[katei (Yuta Saito)]

Issue #18462 has been updated by katei (Yuta Saito).

Status changed from Open to Closed
Assignee set to katei (Yuta Saito)

Updating the ticket status to say that WebAssembly/WASI support has been upstreamed by https://github.com/ruby/ruby/pull/5407

Some examples can be found here: https://github.com/ruby/ruby.wasm


----------------------------------------
Feature #18462: Proposal to merge WASI based WebAssembly support
https://bugs.ruby-lang.org/issues/18462#change-99748

* Author: katei (Yuta Saito)
* Status: Closed
* Priority: Normal
* Assignee: katei (Yuta Saito)
----------------------------------------
# Proposal to merge WASI based WebAssembly support

This is an initial port of WASI based WebAssembly support.
This enables a CRuby binary to be available on Web browser, Serverless Edge environment, and other WebAssembly/WASI embedders. 
Currently this port passes basic and bootstrap test suites not using Thread API.

The upstreaming PR on ruby/ruby is here: https://github.com/ruby/ruby/pull/5407

## Background

For example, CRuby already supports WebAssembly target by Emscripten, but Emscripten heavily depends on JavaScript to emulate some missing features in WebAssembly itself.

In short the WASI is an effort to define a standard set of syscalls for WebAssembly modules, allowing WebAssembly modules to not only be portable across architectures but also be portable across environments implementing this standard set of system calls. The environments includes non JS environments, Edge Computing platforms, IoT devices, and so on.

This is a proposal ticket to support WASI based WebAssembly target.

This is a part of Ruby Association Grant project

## Lexicon

- [WASI](https://wasi.dev): A system call interface for WebAssembly
- [wasi-libc](https://github.com/WebAssembly/wasi-libc): A libc implementation for WebAssembly programs built on top of WASI system calls.

## Current Limitation of WebAssembly and WASI

### Threads

Currently WebAssembly has no threads, and WASI doesn't provide any API to create a thread, but they are [on the roadmap](https://github.com/WebAssembly/threads/blob/main/proposals/threads/Overview.md). This means `Thread.new` doesn't work on this target, and it raises `ENOSUP` for now.

### Register operations

Current WebAssembly doesn't allow to touch the program counter, but they are also [on the roadmap](https://github.com/WebAssembly/stack-switching).
This limitation makes it hard to implement setjmp/longjmp and context-switching on this target, and wasi-libc doesn't provide such implementations.

And also WebAssembly has function local infinite registers, but there is no way to scan the values in a call stack for now.
This limitation makes it unable to mark living objects by Conservative GC in a simple way.

## Patch Overview

This patch is a set of minor changes:

### Adapt to wasi-libc API

wasi-libc is almost compatible with other libc implementations, but it doesn't have some functions.
So this patch adds stub implementations for them.

### Add no thread variant

As mentioned above, WebAssembly has no thread, so this patch adds a thread_none.c, which is a sibling of thread_win32.c and thread_pthread.c. This implementation does nothing around preemptive context switching because there is no native thread.

### Emulate setjmp/longjmp, coroutine, and register scan by Asyncify

As mentioned above, WebAssembly has no context switching feature, but there is an userland technique to pause and resume a WebAssembly process by binary transformation.
This technique is called [Asyncify](https://kripken.github.io/blog/wasm/2019/07/16/asyncify.html).
This patch utilizes it to emulate setjmp/longjmp, coroutine, and register scan for GC.





-- 
https://bugs.ruby-lang.org/