Add a feature request issue for this. Non-determinism is bad for debugging. And I view “production runs” as debugging because when something goes wrong in production once in a blue moon you need to debug that particular run.
Marc
On Aug 8, 2018, at 8:00 AM, Adam adam.mlmb@gmail.com wrote:
|table-ref| (hashtable access) speed being non-deterministic would be all fine as the average access speed should remain constant.
To preserve the possibility of fully deterministic behavior, maybe double hash attack protection by random seeding could be... on by default but can be disabled via a key argument, or, off by default and can be enabled via a key argument, something like this?
Adam
2018-08-08 12:49 GMT+08:00 Marc Feeley feeley@iro.umontreal.ca: No they are not. Doing this would make executions non-deterministic.
Marc
On Aug 8, 2018, at 4:13 AM, Adam adam.mlmb@gmail.com wrote:
Hi Marc,
Are Gambit's hash tables protected against double hash attacks?
E.g. by calculating a random number that's used as hash seed making it impossible for an attacker to produce key hash collissions, https://en.wikipedia.org/wiki/SipHash .
Adam