Rethink state management and option semnatics of proto/wasm/loaded sandbox
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 20/100
調査の方向性
proto/wasm/loaded sandbox の状態管理に関する議論と、関連する PR 128 のスレッドから始めてください。意図された Option と drop のセマンティクスを特定し、その後、ユーザー向けエラーと不変条件違反を分離してください。完了とは、設計について合意され、その影響が文書化または実装されていることを意味します。
索引モデルが issue の本文から書いたものです。
説明
This is taking self by value, so why do we need to move out of these fields? Is it just about the fact that we have drop glue on this type?
One option to get rid of the dynamic check here would be ManuallyDrop, but I don't know if we like the tradeoff of (closer to what we actually want, no unnecessary dynamic checks) to increased unsafe code surface, and I suppose we would still need to have a flag that let the Drop impl know whether or not the contents had been moved (or use ManuallyDrop<Self> to write an into_inner() function that removes the contents of the sandbox, manually updates the counters, and never runs the drop glue at all).
Relatedly, I think that scattered throughout our errors in general, we have a mix of "this means the user did something wrong, and they should be better" with "this means this is a fundamental invariant that we believed would always be true but was somehow violated". I would like us to separate these in an easily visible way (akin to rustc errors vs ICEs), since they have quite different consequences. I wonder if it is reasonable to panic in the latter case, since if we were wrong about one invariant, who knows what else we were wrong about...
Sorry, this comment has become a bit long and large in scope, so feel free to not consider it a blocker for this PR, but perhaps think a little bit about whether the Option semantics are indeed what we want.
Originally posted by @syntactically in https://github.com/hyperlight-dev/hyperlight-wasm/pull/128#discussion_r2239536449
- 主要言語
- Rust
- スター
- 728
- フォーク
- 39
- 平均マージ
- 2日 3時間
- マージ済み PR（30日）
- 25
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
hyperlight-dev/hyperlight-wasm のほかの issue
-
lifecycle/needs review
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
-
lifecycle/needs review
難易度 4/5 3〜5日 初心者へのやさしさ 55/100
-
lifecycle/needs review
難易度 4/5 3〜5日 初心者へのやさしさ 38/100
-
use the #[guest_func] macro on `init_wasm_runtime` instead of manually calling register_function? オープンlifecycle/needs review
難易度 3/5 1〜2日 初心者へのやさしさ 35/100
hyperlight-dev/hyperlight-wasm#395 · コメント 1 件 · リアクション 1 件 ·
-
lifecycle/needs review
難易度 2/5 1〜3時間 初心者へのやさしさ 48/100
hyperlight-dev/hyperlight-wasm の issue をすべて見る
似ている issue
-
bug
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
yantrikos/yantrik-os#255 ·
-
bug CLI custom-model
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
raphamorim/rio#1956 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
rust-bitcoin/rust-bitcoin#6930 · コメント 1 件 ·