4 ms·
Another case where using immutable data by default would have prevented any shenanigans. It also shows the highly entangled relationship between state and compl
by beders 6y ago
Another case where using immutable data by default would have prevented any shenanigans.
It also shows the highly entangled relationship between state and complexity.
(in this case, the env object)
Immutable data forces you to design your system in a different way and remove layers of complexity.
- ed25519FUUU 6y agoHow would that help here? They would just exchange one piece immutable data (un-signed in user cookie) with another piece of wrong immutable data (someone else’s session).
- beders 6y agoA mutable object 'env' was shared across threads.
- beders 6y ago"While the immediate risk has been mitigated, we worked with the maintainer of Unicorn to upstream the change to make new requests allocate their own environment hashes. If Unicorn uses new hashes for each environment, it removes the possibility of one request mistakenly getting a hold of an object that can affect the next request."
- brundolf 6y agoWhile in general I agree, in this case that aspect of the problem entirely came down to "don't use object pools that span multiple requests". That's a conscious optimization that was made and then retracted, not a subtlety that accidentally slipped in due to mutability itself.
- beders 6y agoobject pools == mutability (why else would you keep objects around in a pool)
- brundolf 6y agoObject pools require mutability; by no means does mutability require you to use object pools
- beders 6y agoObvious. But not what I meant. I meant that it was a conscious decision to use an object pool and re-use objects. That doesn't happen with immutable by default languages. Ergo, these particular kinds of bugs just don't happen.
- joebob42 6y agoI guess the point here is that an object pool isn't the default anyways: theyve chosen to do something non-default for performance, which you can still do in immutable by default languages.