3 ms·
The basic idea clicked pretty quickly with me. A restricted memory model that sort-of guarantees a number of awful things can't happen. Makes sense. But how
by retrac 6y ago
The basic idea clicked pretty quickly with me. A restricted memory model that sort-of guarantees a number of awful things can't happen. Makes sense. But how do I express working things in it? The obvious approaches conflict with the rules.
A simple emulator in a C-style might consist of a UI thread and a compute thread. The UI thread sends messages to the compute thread. You can have some timing though not usually safety/crash issues if you do this without locks. So maybe you do or don't lock that. But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. Simple, fast, almost-safe.
How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? It's hard to get that right.
- zozbot234 6y ago> But the UI thread can pretty wantonly read the compute thread's memory array to render it for graphics and may just get tearing like real hardware. ... How do I express that sort of arrangement in Rust's type system and make it actually safe and fast? You can use atomic types with custom memory ordering, just like you would in C.