On 12.02.2016 20:12, Andrei Alexandrescu wrote:
https://github.com/D-Programming-Language/phobos/pull/3991
A short while ago Dicebot discussed the notion of using the allocator to
store the reference count of objects (and generally metadata). The
allocator seems to be a good place because in a way it's a source of
"ground truth" - no matter how data is qualified, it originated as
untyped mutable bytes from the allocator.
So after thinking a bit I managed to convince myself that the affixes in
an AffixAllocator can be accessed with removing immutable, but without
actually breaking any guarantee made by the type system. (Affixes are
extra bytes allocated before and after the actual allocation.) The logic
goes as follows:
* If the buffer is mutable, then the allocator assumes it hasn't been
shared across threads, so it returns a reference to a mutable affix.
* If the buffer is const, then the allocator must conservatively assume
it might have been immutable and subsequently shared among threads.
Therefore, several threads may request the affix of the same buffer
simultaneously. So it returns a reference to a shared affix.
* If the buffer is shared, then the allocator assumes again several
threads may access the affix so it returns a reference to a shared affix.
One simple way to look at this is: the allocator keeps an associative
array mapping allocated buffers to metadata (e.g. reference counts). The
allocated buffers may be immutable, which doesn't require the metadata
to be immutable as well. The only difference between an approach based
on an associative array and AffixAllocator is that the latter is faster
(the association is fixed by layout).
Destroy!
Andrei
The first thing that comes to mind is that accessing a global
associative array is not 'pure'.
