We have recently started working on a new crate, stdworld. The basic premise of stdworld is that certain things can only be called from certain places, and we can define those places in the type system. Ideally the compiler would manage those "places" automatically but since that requires compiler support we won't bother with it, this is a library-only solution.
We started this crate because we wanted code unloading in safe rust. In particular, rust is traditionally incompatible with code unloading:
- What are the requirements for unloading a library (`dlclose`)? · Issue #526 · rust-lang/unsafe-code-guidelines · GitHub
- hexchat since 0.3.0 is unsound · Issue #913 · rustsec/advisory-db · GitHub
- https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/How.20to.20safely.20drop.20wasmtime.3F
But since we were already trying to solve code unloading with a solution that would also be effective for signal safety (with roughly the same level of complexity), we decided, why not just extend it to signal safety and be done with it? It's not like we have anything to lose. (Yes, we like pain, clearly.)
This crate was inspired by the following work:
qcellcrate.- our own
selfrefcrate. - tom7's PhD: Modal Types for Mobile Code
- rust itself, in particular
SendandSync, and, more importantly,UnwindSafeandRefUnwindSafe.
Additionally, despite strong similarities, the following was not an inspiration for this project:
- Implement struct_target_features for non-generic functions. by veluca93 · Pull Request #129881 · rust-lang/rust · GitHub
(side note: "avx drop" when)
(Tho this did prompt us to push the crate and ask for contributors. On the off chance that our work here influences the above and we end up with "implicit worlds" somehow, maybe even with Drop support... having to put <W: World> everywhere and pass w around to everything, plus not being able to use Drop because alloc is a separate world now, is a bit of a pain and arguably this project's achilles heel.)
Would anyone be interested in this?