Rethink state management and option semnatics of proto/wasm/loaded sandbox
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 20/100
Hướng nghiên cứu
Bắt đầu với cuộc thảo luận về quản lý trạng thái của proto/wasm/loaded sandbox và chuỗi thảo luận PR 128 liên quan. Xác định ngữ nghĩa Option và drop dự kiến, sau đó phân tách các lỗi hướng đến người dùng khỏi các vi phạm bất biến; được coi là hoàn tất khi thiết kế đã được thống nhất và các hệ quả của nó đã được ghi lại hoặc triển khai.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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
- Ngôn ngữ chính
- Rust
- Star
- 728
- Fork
- 39
- Merge trung bình
- 2 ngày 3 giờ
- Pull request đã merge (30 ngày)
- 25
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của hyperlight-dev/hyperlight-wasm
-
lifecycle/needs review
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
-
lifecycle/needs review
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 55/100
-
Can't update to wasmtime 48 Đang mởlifecycle/needs review
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 38/100
-
use the #[guest_func] macro on `init_wasm_runtime` instead of manually calling register_function? Đang mởlifecycle/needs review
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
hyperlight-dev/hyperlight-wasm#395 · 1 bình luận · 1 reaction ·
-
lifecycle/needs review
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 48/100
Tất cả issue của hyperlight-dev/hyperlight-wasm
Issue tương tự
-
bug github_actions
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
registrystack/registry-stack#1393 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
rocky-data/rocky#2181 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Đang mởbot:ai-assisted component:indexer QA-roadmap status:untriaged
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
midnightntwrk/midnight-indexer#1557 ·