pchickey opened PR #1961 from pch/sync_wasi_pipe
to main
:
Follow up to #1949
When we went to integrate this code, we discovered that we needed these virtual pipes to be
Send
andSync
. So, I have switched the internal types fromCell/RefCell/Rc
toArc/RwLock
.The
RwLock.{read, write}
results are alwaysunwrap()
ed because this code does not expose any way for a panic to occur while a lock is held.<!--
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.
-->
pchickey requested acfoltzer for a review on PR #1961.
acfoltzer submitted PR Review.
pchickey updated PR #1961 from pch/sync_wasi_pipe
to main
:
Follow up to #1949
When we went to integrate this code, we discovered that we needed these virtual pipes to be
Send
andSync
. So, I have switched the internal types fromCell/RefCell/Rc
toArc/RwLock
.The
RwLock.{read, write}
results are alwaysunwrap()
ed because this code does not expose any way for a panic to occur while a lock is held.<!--
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.
-->
pchickey edited PR #1961 from pch/sync_wasi_pipe
to main
:
Follow up to #1949
When we went to integrate this code, we discovered that we needed these virtual pipes to be
Send
andSync
. So, I have switched the internal types fromCell/RefCell/Rc
toArc/RwLock
.The
RwLock.{read, write}
results are alwaysunwrap()
ed because this code does not expose any way for a panic to occur while a lock is held.<!--
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.
-->
pchickey edited PR #1961 from pch/sync_wasi_pipe
to main
:
Follow up to #1949
When we went to integrate this code, we discovered that we needed these virtual pipes to be
Send
andSync
. So, I have switched the internal types fromCell/RefCell/Rc
toArc/RwLock
.The
RwLock.{read, write}
results are alwaysunwrap()
ed because this code does not expose any way for a panic to occur while a lock is held.We also identified that the
Handle::try_clone
method was incorrect, and did a manual impl ofClone
with the correct semantics.<!--
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.
-->
acfoltzer submitted PR Review.
pchickey merged PR #1961.
Last updated: Nov 22 2024 at 16:03 UTC