Stream: git-wasmtime

Topic: wasmtime / PR #2434 Implement support for `async` functio...

Wasmtime GitHub notifications bot (Nov 19 2020 at 23:17):

alexcrichton opened PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 19 2020 at 23:19):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 19 2020 at 23:32):

cfallin submitted PR Review.

Wasmtime GitHub notifications bot (Nov 19 2020 at 23:32):

cfallin created PR Review Comment:

The bottom 64 bits of v8 -- v15 (aka q8 -- q15) are callee-saved as well (yeah, it's kinda weird!). stp q8, q9, ..., etc. should work.

Wasmtime GitHub notifications bot (Nov 20 2020 at 06:10):

alexcrichton submitted PR Review.

Wasmtime GitHub notifications bot (Nov 20 2020 at 06:10):

alexcrichton created PR Review Comment:

I think this is the first time I've done aarch64 assembly, so want to confirm something to make sure. According to this the low 64-bits of the vector registers are dN, does that sound right? From what this is saying though is it true that d8 to d31 all need to be saved? (wow that's a lot of registers)

Wasmtime GitHub notifications bot (Nov 20 2020 at 06:41):

cfallin submitted PR Review.

Wasmtime GitHub notifications bot (Nov 20 2020 at 06:41):

cfallin created PR Review Comment:

Err, sorry, d8 -- d15, yes. That document is a bit perplexing to me, though; the AArch64 "AAPCS" (standard ABI) (direct pdf link to ABI doc, or ARM's download page) says in 5.1.2 that v0 -- v7 and v16 -- v31 are caller-saved, and that's what we've implemented elsewhere (and what our friendly local ARM engineers have pointed us to -- see e.g. #2254).

I'm actually wondering if the ARM page you've linked has a typo; they segment the registers into 8-15 and 16-31, but write "callee-save" for both; there'd be no reason to write the two ranges separately otherwise. In any case, hopefully the above helps somewhat!

Wasmtime GitHub notifications bot (Nov 20 2020 at 15:27):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 20 2020 at 15:32):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Nov 20 2020 at 15:34):

alexcrichton submitted PR Review.

Wasmtime GitHub notifications bot (Nov 20 2020 at 15:34):

alexcrichton created PR Review Comment:

Oh interesting! That does indeed look like a typo. Ok cool, then I think this should be handled in e40bd97

Wasmtime GitHub notifications bot (Jan 21 2021 at 21:15):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Jan 26 2021 at 19:53):

smacleod submitted PR Review.

Wasmtime GitHub notifications bot (Jan 26 2021 at 19:53):

smacleod submitted PR Review.

Wasmtime GitHub notifications bot (Jan 26 2021 at 19:53):

smacleod created PR Review Comment:

    // instruction which just aborts, but I don't know such an instruction in
    // aarch64 land.

Wasmtime GitHub notifications bot (Jan 26 2021 at 20:00):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Jan 29 2021 at 16:07):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Jan 29 2021 at 16:46):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Jan 29 2021 at 18:02):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Jan 29 2021 at 18:02):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 01 2021 at 20:08):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 01 2021 at 21:10):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 01 2021 at 23:36):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 02 2021 at 19:21):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 04 2021 at 02:24):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Feb 04 2021 at 02:24):

peterhuene created PR Review Comment:

So I think CreateFiberEx should probably be used here as we probably want stack_size to be the reserve size and not the commit size on Windows.

CreateFiber's dwStackSize parameter is the commit size and 1 MiB is typically used for the reserve size (it's from the PE header, but 1 MiB is what Microsoft's linker uses).

If dwStackSize is larger than the default reserve size, then it reserves dwStackSize rounded up 1 MiB as the reserve size.

With CreateFiberEx, there are two parameters: dwStackCommitSize and dwStackReserveSize. The former we'll want to pass 0 to get the default commit size (which will be 1 page in size, I believe).

So suggested change:

 let fiber = CreateFiberEx(
    0,
    stack_size,
    1, // FIBER_FLAG_FLOAT_SWITCH (might not be in the winapi crate)
    Some(fiber_start::<F, A, B, C>),
    &*state as *const StartState as *mut _,
);

This should help prevent the fiber stacks from counting towards the commit limit upfront.

Wasmtime GitHub notifications bot (Feb 04 2021 at 02:25):

peterhuene edited PR Review Comment.

Wasmtime GitHub notifications bot (Feb 04 2021 at 15:16):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 04 2021 at 15:58):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 04 2021 at 16:00):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 04 2021 at 19:08):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 04 2021 at 19:27):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 04 2021 at 19:58):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 05 2021 at 06:48):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Feb 05 2021 at 06:48):

peterhuene created PR Review Comment:

    // The first 16 bytes of stack are reserved for metadata, so we start
    // storing values beneath that.

Wasmtime GitHub notifications bot (Feb 05 2021 at 19:59):

alexcrichton updated PR #2434 from async to main:

This is an implementation of [RFC 2] in Wasmtime which is to support
async-defined host functions. At a high level support is added by
executing WebAssembly code that might invoke an asynchronous host
function on a separate native stack. When the host function's future is
not ready we switch back to the main native stack to continue execution.

There's a whole bunch of details in this commit, and it's a bit much to
go over them all here in this commit message. The most important changes
here are:

• A new wasmtime-fiber crate has been written to manage the low-level
  details of stack-switching. Unixes use mmap to allocate a stack and
  Windows uses the native fibers implementation. We'll surely want to
  refactor this to move stack allocation elsewhere in the future. Fibers
  are intended to be relatively general with a lot of type paremters to
  fling values back and forth across suspension points. The whole crate
  is a giant wad of unsafe unfortunately and involves handwritten
  assembly with custom dwarf CFI directives to boot. Definitely deserves
  a close eye in review!

• The Store type has two new methods -- block_on and on_fiber
  which bridge between the async and non-async worlds. Lots of unsafe
  fiddly bits here as we're trying to communicate context pointers
  between disparate portions of the code. Extra eyes and care in review
  is greatly appreciated.

• The APIs for binding async functions are unfortunately pretty ugly
  in Func. This is mostly due to language limitations and compiler
  bugs (I believe) in Rust. Instead of Func::wrap we have a
  Func::wrapN_async family of methods, and we've also got a whole
  bunch of Func::getN_async methods now too. It may be worth
  rethinking the API of Func to try to make the documentation page
  actually grok'able.

This isn't super heavily tested but the various test should suffice for
engaging hopefully nearly all the infrastructure in one form or another.
This is just the start though!

[RFC 2]: https://github.com/bytecodealliance/rfcs/pull/2

<!--

Please ensure that the following steps are all taken care of before submitting
the PR.

• [ ] This has been discussed in issue #..., or if not, please tell us why
  here.

• [ ] A short description of what this does, why it is needed; if the
  description becomes long, the matter should probably be discussed in an issue
  first.

• [ ] This PR contains test cases, if meaningful.

• [ ] A reviewer from the core maintainer team has been assigned for this PR.
  If you don't know who could review this, please indicate so. The list of
  suggested reviewers on the right can help you.

Please ensure all communication adheres to the code of conduct.
-->

Wasmtime GitHub notifications bot (Feb 18 2021 at 15:49):

alexcrichton updated PR #2434 from async to main.

Wasmtime GitHub notifications bot (Feb 18 2021 at 15:50):

alexcrichton updated PR #2434 from async to main.

Wasmtime GitHub notifications bot (Feb 26 2021 at 15:12):

alexcrichton requested peterhuene for a review on PR #2434.

Wasmtime GitHub notifications bot (Feb 26 2021 at 19:12):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Feb 26 2021 at 19:12):

peterhuene created PR Review Comment:

I'll ping some Microsoft debugger folks to see if it's a known limitation of StackWalkEx when the given thread is a fiber. I suspect RtlVirtualUnwind might not have this problem.

Wasmtime GitHub notifications bot (Feb 26 2021 at 20:14):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Feb 26 2021 at 20:14):

peterhuene created PR Review Comment:

These methods are the most heavily optimized...

Perhaps I'm reading this sentence wrong, but "most heavily optimized" sounds like the opposite intention.

Wasmtime GitHub notifications bot (Feb 26 2021 at 20:49):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Feb 26 2021 at 20:49):

peterhuene created PR Review Comment:

        // We don't actually care about the fiber's return value here (no one's

Wasmtime GitHub notifications bot (Feb 26 2021 at 20:52):

peterhuene submitted PR Review.

Wasmtime GitHub notifications bot (Feb 26 2021 at 21:31):

alexcrichton updated PR #2434 from async to main.

Wasmtime GitHub notifications bot (Feb 26 2021 at 22:19):

alexcrichton merged PR #2434.

Last updated: Nov 22 2024 at 17:03 UTC