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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
cfallin submitted PR Review.
cfallin created PR Review Comment:
The bottom 64 bits of
v8
--v15
(akaq8
--q15
) are callee-saved as well (yeah, it's kinda weird!).stp q8, q9, ...
, etc. should work.
alexcrichton submitted PR Review.
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 thatd8
tod31
all need to be saved? (wow that's a lot of registers)
cfallin submitted PR Review.
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 thatv0
--v7
andv16
--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!
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
alexcrichton submitted PR Review.
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
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
smacleod submitted PR Review.
smacleod submitted PR Review.
smacleod created PR Review Comment:
// instruction which just aborts, but I don't know such an instruction in // aarch64 land.
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
peterhuene submitted PR Review.
peterhuene created PR Review Comment:
So I think
CreateFiberEx
should probably be used here as we probably wantstack_size
to be the reserve size and not the commit size on Windows.
CreateFiber
'sdwStackSize
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 reservesdwStackSize
rounded up 1 MiB as the reserve size.With
CreateFiberEx
, there are two parameters:dwStackCommitSize
anddwStackReserveSize
. 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.
peterhuene edited PR Review Comment.
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
peterhuene submitted PR Review.
peterhuene created PR Review Comment:
// The first 16 bytes of stack are reserved for metadata, so we start // storing values beneath that.
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 usemmap
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 ofunsafe
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
andon_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
inFunc
. This is mostly due to language limitations and compiler
bugs (I believe) in Rust. Instead ofFunc::wrap
we have a
Func::wrapN_async
family of methods, and we've also got a whole
bunch ofFunc::getN_async
methods now too. It may be worth
rethinking the API ofFunc
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.
-->
alexcrichton updated PR #2434 from async
to main
.
alexcrichton updated PR #2434 from async
to main
.
alexcrichton requested peterhuene for a review on PR #2434.
peterhuene submitted PR Review.
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 suspectRtlVirtualUnwind
might not have this problem.
peterhuene submitted PR Review.
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.
peterhuene submitted PR Review.
peterhuene created PR Review Comment:
// We don't actually care about the fiber's return value here (no one's
peterhuene submitted PR Review.
alexcrichton updated PR #2434 from async
to main
.
alexcrichton merged PR #2434.
Last updated: Dec 23 2024 at 13:07 UTC