Rethink state management and option semnatics of proto/wasm/loaded sandbox
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 20/100
Línea de trabajo
Comienza con la discusión sobre la gestión del estado de proto/wasm/loaded sandbox y el hilo relacionado de PR 128. Determina la semántica prevista de Option y drop, y luego separa los errores visibles para el usuario de las violaciones de invariantes; se considera terminado cuando el diseño está acordado y sus consecuencias están documentadas o implementadas.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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
- Lenguaje dominante
- Rust
- Estrellas
- 728
- Forks
- 39
- Merge medio
- 2 d 3 h
- PR fusionados (30 d)
- 25
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de hyperlight-dev/hyperlight-wasm
-
lifecycle/needs review
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
-
lifecycle/needs review
Dificultad 4/5 3-5 días Aptitud para principiantes 55/100
-
Can't update to wasmtime 48 Abiertolifecycle/needs review
Dificultad 4/5 3-5 días Aptitud para principiantes 38/100
-
use the #[guest_func] macro on `init_wasm_runtime` instead of manually calling register_function? Abiertolifecycle/needs review
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
hyperlight-dev/hyperlight-wasm#395 · 1 comentario · 1 reacción ·
-
lifecycle/needs review
Dificultad 2/5 1-3 horas Aptitud para principiantes 48/100
Todos los issues de hyperlight-dev/hyperlight-wasm
Issues similares
-
Replayed reasoning items send "content": null, which the Responses API schema does not permit Abiertobug CLI custom-model
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
rust-bitcoin/rust-bitcoin#6930 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
fulcrumgenomics/ferro-hgvs#2251 ·
-
Missing examples for `Allocator` AbiertoA-allocators A-docs C-enhancement T-libs
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100