stateroom VS rust-playground

In the case of containers it gets tricky because of how it interacts with the scheduler (e.g. if a node is idle but has a bunch of paused containers that could be unpaused at any time, the scheduler has to decide how to proceed), but I love the concept. It's something I've thought a bit about in a world where the server can be compiled to WebAssembly, because it's imaginable to suspend it and serialize the memory state so that it can be sent off to storage somewhere and pulled out when the next request comes in. This was actually part of the motivation behind a library I wrote called Stateroom (https://github.com/drifting-in-space/stateroom), which creates a stateful WebSocket server as a WebAssembly module, but I haven't yet implemented the ability to freeze the state of the module between requests.

> "just drop it in and it just works" for self hosted websocket systems

I was also been underwhelmed by options in this area, so I've been working on a Rust library called Jamsocket[1]. The idea is that all you need to do is implement a trait, overload the functions for the events you want to handle (new connection, message, etc.) and deploy it.

I still need to work on production aspects of it, but it's in a state where you can play with it for local development, so I figured I'd share it here in case any Rust developers want to tinker with it.

[1] https://github.com/jamsocket/jamsocket

If you have an object that's !Unpin, then Miri will not apply uniqueness rules to anything containing it [0], including boxes and &mut references. (In the example code, replacing the PhantomPinned with a () will make Miri complain again.) This is considered a temporary (if long-lived) measure to allow async executors to manipulate pinned futures without invalidating all their references and whatnot. Thus, it might be seen as undetected UB, in lieu of a permanent solution.

[0] https://play.rust-lang.org/?version=stable&mode=debug&editio...

That would be true if you used `Vec::clear` too, it doesn't allocate a new vector. My point was that you still end up running Drop implementations with RepeatedField, just not all at once. See https://play.rust-lang.org/?version=stable&mode=debug&editio...

That's a valid Unix path, but rust's quoting does nothing to stop it: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Self-referential structs work fine in Rust and always have.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

The compiler will correctly prevent you from moving the value.

The other way to have a struct that starts out as non-self-referential and then becomes self-referential can be achieved with `unsafe` and `Pin::new_unchecked`, which is how `async {}` is handled.

In rust as currently stands: https://play.rust-lang.org/?version=stable&mode=debug&editio...

On the other hand, both this wrapper and yours are counterproductive if the element size is dynamic (e.g. perhaps you're dealing with some nonsense like:)

    struct ITableColumn {

Overflow checks turn into two's compliments' wrapping, but that's only considered acceptable because bounds checks are not turned off.

https://play.rust-lang.org/?version=stable&mode=release&edit...

I have no idea what you're talking about, but it sounds unnecessarily complicated and why I don't use Rust for any serious work.

This demonstrates the ABA problem in safe Rust: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Substitute the sleep with a combination of doing computation/work and the OS thread scheduler, and you can see how the bug surfaces.

You can also try Rust online using the Rust playground: https://play.rust-lang.org/

(Click ... beside build to get assembly) https://play.rust-lang.org/?version=stable&mode=release&edit...

Unfortunately the go playground doesn't seem to support emitting assembly?