On Sun, 27 Oct 2019 20:20:07 +0000 roger peppe <rogpe...@gmail.com> wrote:
> If two things aren't writing concurrently to the same address, what's the > problem? I've got an impression that OP is concerned about arriving at inconsistent/"impossible" shared state (due to poorly thought architecture). 30-20yrs ago this kind of bug have had haunted codebases still using global state, where procedure X set some state in S and precomputed S' that was then being used by procedure Z; but in meantime the S, and only S, had got modified (by some procedure Y in the middle). So, from the pov of Z (that assumed S' ← S) we have had got to an "impossible state". In event-loop driven programs often this happened in seemingly random ways. @Gert, <gert.cuyk...@gmail.com> This indeed can easily can be "achieved" in a single threading Go code that uses slices (pointers) to the shared state. It was, it is, and it always will be a programmer's error. More, no known to me code analysis tool could comprehend changes to your shared state in full and then flag only the wrongs. An AI capable of that would also be capable of replacing us at our desks ;) Hope this helps, -- Wojciech S. Czarnecki << ^oo^ >> OHIR-RIPE -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/20191028112516.750f1649%40zuzia.
