3 ms·
I don’t understand what you’re saying. Haskell (specifically GHC) has perfectly thread-safe secretly mutable thunks. Are you suggesting there’s a problem with
by tome 11y ago
I don’t understand what you’re saying. Haskell (specifically GHC) has perfectly thread-safe secretly mutable thunks. Are you suggesting there’s a problem with doing this in a strict language? An impure language? Or something else? I don’t see why you’d say there’s a problem with a secretly mutating thunk datatype.
- catnaroek 11y agoHe means that updates to those thunks have to be guaranteed atomic. This can be achieved in three ways: (0) disallowing threads running in parallel, (1) using atomic operations [only works on small enough pieces of data, such as pointers to boxed data], or (2) using explicit concurrency control [locks, whatever]. We know GHC doesn't do the first, and the third would also be overkill, so it probably does the second. This also explains why unboxed data in GHC is less lazy.