Soni L. (Dec 07 2024 at 11:33): Soni L. (Dec 07 2024 at 11:33):does wasmtime use raw pointers with lifetimes? (e.g. https://chaos.social/@SoniEx2/113611229674401347 ) if not why not? if so why's it not upstream? (there's no way we're the first to come up with this idea. we're probably not even the first to publish it. and yet, we never hear of it from anyone else. if it isn't useful, then why was it so useful for our needs? granted retrofitting this on an existing codebase is a pain and a half...)
bjorn3 (Dec 07 2024 at 21:39):The actual lifetime of most values that are behind raw pointers is equal to the lifetime of the Store, however as the pointers are stored in the Store themself (which can be freely moved), Rust doesn't allow producing a 'store. That is the main reason why raw pointers are used AFAIK. Raw pointers with lifetimes are only useful when the reason you are using raw pointers is because of aliasing or the type behind the pointer not being known at compile time. It is not useful when the reason is that there is no way to express the runtime lifetime in a way that the compiler understands at compiletime.
Soni L. (Dec 07 2024 at 21:57):well, in that case may we introduce you to selfref? safe representation of the Store (and 'store) is exactly the intended use-case of selfref
Soni L. (Dec 07 2024 at 21:58):which we're also trying to get rid of https://chaos.social/@SoniEx2/113577841740469472
Soni L. (Dec 07 2024 at 22:01):(as it turns out we ran into these limitations of rust pretty quickly with hexchat plugins. everyone told us it was unsolvable so we solved it ourselves.)
Soni L. (Dec 08 2024 at 01:26):this is how we just described selfref to someone:
rust is generally thought to have no support for self references, but in truth the language has limited support for some forms of self references. it is possible to borrow a struct for the same lifetime as contained in said struct, creating a self-reference. this comes with some limitations however, and selfref attempts to address those limitations, namely the ability to move the struct's container (obviously you can't move the actual struct that has self-references because that would invalidate the references, but you can move e.g. the
Box<Struct>)unlike similar crates, selfref tries to take advantage of rust's limited support for self-references.
we've never seen anyone else do this
(they just use raw pointers lmao)
(literally, that's what e.g. wasmtime does)
bjorn3 (Dec 08 2024 at 09:55):Does selfref allow modifying the thing the reference points to? If not, wasmtime can't use it as we need to be able to add new things to the Store. If however it allows arbitrary modifications, then it is unsound as you could remove and drop something that still has a reference to it. Wasmtime's use of self-references works only because Store is append-only. I don't see anything in the selfref api that allows enforcing that.
Soni L. (Dec 08 2024 at 10:18):yes, to the extent that you have to use the usual safe rust cells (or qcell's extension of them).
Soni L. (Dec 08 2024 at 10:20):like, we can't stop you from using cells, and that is kinda the point
hexchat-unsafe-plugin 2.4.0-pre1 (which is probably an ABI break so it should be 3.0.0-pre1 but anyway) uses selfref with various cells, look for PluginEnvironment in src/mock
Soni L. (Dec 08 2024 at 10:22):(ngl the main reason we stopped working on hexchat-unsafe-plugin was the varargs. and burning out of rust at some point.)
Soni L. (Dec 08 2024 at 10:50):in theory it should be possible to grow a Vec of self-references "in-place" but we don't think that's possible in safe Rust today. but you can still copy everything to a new Vec and set up the correct references that way.
Last updated: Dec 23 2024 at 12:05 UTC