On Thursday, 24 March 2016 at 11:18:06 UTC, Nordlöw wrote:
Could somebody briefly outline how the thread-locality
(non-GC-locked) of allocators relates to the purity of the
containers using them?
This because I want to move forward with optimizations in my
knowledge graph that requires GC-free array containers storing
value typed elements (integers) which preferrably has pure API.
Specifically, I want to use something like
https://github.com/economicmodeling/containers/blob/master/src/containers/dynamicarray.d
that is `@safe pure` and uses lock-free allocations in a
heavily multi-threaded application.
If I want purity aswell which `std.experimental.allocators` are
possible?
Currently almost nothing in `std.experimental.allocators` is
explicitly marked as pure, except for some of the things in
./common.d
(https://github.com/D-Programming-Language/phobos/pull/3957
*shameless plug*). Thankfully make, makeArray, dispose and some
of the allocators are templates, so you can rely on attribute
inference.
The most important thing is that you need to have pure `allocate`
and `deallocate` methods. After this `make` and friends will work
like magic (at least for types with pure `this` and `~this`).
`pure` statefull allocator essentially means that it has to be
thread-local, so there are no global side-effects. Essentially,
to achieve this you can make a large initial allocation in each
thread (even from a non-pure allocator) and then you can make
`pure` sub-allocations out of it.
You can read more about my adventures with my `pure` smart
pointer here:
http://forum.dlang.org/post/[email protected]
http://forum.dlang.org/post/[email protected]
