3 ms·
Broadly enjoyed my read, though I do have a nitpick here: >The absence of side effects or stalls cannot be enforced by the type system ... Side effects is pro
by Groxx 2mo ago
Broadly enjoyed my read, though I do have a nitpick here:
>The absence of side effects or stalls cannot be enforced by the type system ...
Side effects is probably correct, but stalls would imply wasm code that calls out to a long-time blocking function - that's generally quite easy to type-system-ify, and wasm stuff often does so with promise-like constructs. So there would be a need for spacetimedb-side markers for "this func might do HTTP", but that kind of marker for WASM-contact-able code is very much a normal expectation.
If they don't have that kind of marker, and do allow blocking calls in their beta API, then yeah - huge problem with that kind of internal structure (shared global lock), completely agreed.
- cloutiertyler 2mo agoI would encourage you to read our technical write up in reply to this article: https://spacetimedb.com/blog/benchmarking https://spacetimedb.com/blog/benchmarking
- Groxx 2mo agoDoesn't really cover the types used in the beta APIs. Nor would I expect it to though. Is there a more technical explanation post somewhere? I'm definitely curious how it works, and I like the core idea quite a bit - I'm fairly convinced that WASM uses like this are going to grow immensely, and "it's just a global mutex/single thread" reduces complexity so much that it's always interesting to see where it's possible to use. The latency+throughout brings many questions though, like "are you holding responding to writes and any reads that occur after until changes are written to disk" and "if so I kinda assume that change log is constantly streamed to disk with a moving high water mark for responses". I can generally see how that'd hit such benchmarks, especially with non-dirty reads being near instant, but details are always interesting.
- cloutiertyler 2mo agoI don't really have a deep technical explanation blog post out, but we should definitely publish one. I can say that your last paragraph is essentially correct though. It works exactly that way.
- Groxx 2mo agoIs there anything on how a multi-node cluster works (I'm kinda assuming there's something since it makes "single" mentions a few times)? Application-level sharding is always an option (and multiple things I've worked on have used it to great effect), but anything automatic seems likely gnarly and fun to learn about, if it recovers some of the naive perf loss of "just hold the lock while doing rpc to other nodes".
- cloutiertyler 1mo agoI'm publishing a post this week about it.