John Cowan <xxxxxx@mercury.ccil.org> writes:

>> - The last point combined with the other two points: on one run of your
>>   program the two whole-table operations *do* have the same order, in
>>   another run they don't.
>
> I don't see that at all: if what your program does in the two runs is the
> same, then the results out of the hash table will be the same, unless the
> hash table implements salt (as discussed by Alex earlier).

I meant to say, if the input or code change trivially, it can affect
whether the delete operation between the whole-table operations causes a
compaction or not.  So if your code relies on the order remaining same
across the two whole-table operations, it might work most of the time,
then fail seemingly arbitrarily when change in input or surrounding code
lead to that one delete operation to cause a compaction.

>> It really has good Heisenbug potential.  People should absolutely never
>> rely on the order in any way if they want to make sure there's no loaded
>> guns pointing at their feet.
>
> I agree with that, but it's not because the result is non-deterministic,
> it's because we can't readily predict it.  It's like relying on pseudo-random
> numbers, which are just as deterministic.

I guess it's an abuse of terminology.  I changed "nondeterministic" to
"unpredictable" now.

Taylan