Email list hosting service & mailing list manager

New names for some operations taylanbayirli@xxxxxx (13 Sep 2015 12:13 UTC)
Re: New names for some operations John Cowan (13 Sep 2015 19:01 UTC)
Re: New names for some operations taylanbayirli@xxxxxx (13 Sep 2015 20:19 UTC)
Re: New names for some operations John Cowan (13 Sep 2015 22:20 UTC)
Re: New names for some operations taylanbayirli@xxxxxx (14 Sep 2015 08:29 UTC)
Re: New names for some operations Shiro Kawai (13 Sep 2015 23:28 UTC)
Re: New names for some operations John Cowan (13 Sep 2015 23:45 UTC)
Re: New names for some operations Shiro Kawai (13 Sep 2015 19:27 UTC)
Re: New names for some operations taylanbayirli@xxxxxx (13 Sep 2015 20:04 UTC)
Re: New names for some operations John Cowan (13 Sep 2015 20:11 UTC)
Re: New names for some operations Shiro Kawai (13 Sep 2015 20:25 UTC)
Re: New names for some operations taylanbayirli@xxxxxx (13 Sep 2015 21:46 UTC)
Re: New names for some operations taylanbayirli@xxxxxx (14 Sep 2015 09:39 UTC)
Re: New names for some operations Arthur A. Gleckler (13 Sep 2015 19:42 UTC)
Re: New names for some operations taylanbayirli@xxxxxx (13 Sep 2015 19:57 UTC)
Re: New names for some operations Arthur A. Gleckler (14 Sep 2015 03:25 UTC)
Re: New names for some operations John Cowan (14 Sep 2015 03:38 UTC)

Re: New names for some operations taylanbayirli@xxxxxx 14 Sep 2015 08:29 UTC

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