ftl::TaskScheduler allocator support
Opened this issue · 7 comments
As we start to allocate more and more with various improvements, we need a way of getting an allocator in there. My ideal would be to use std::polymorphic_allocator<byte> + std::memory_resource but that's c++17. Then our options are to reimplement memory_resource etc. in abseil style (there is a boost license c++11 impl of both), or to embed the allocator into the type. As a task scheduler is basically a global, embedding it in the type isn't the end of the world but would also require everything to be in the header which is less than ideal.
I haven't read into polymorphic_allocator or memory_resource much, but they both look much better than the default std allocators. When I was first creating this library, I was looking at EASTL, due to the pain of std allocators.
With polymorphic_allocator, can this be used with std containers? Or would we need to replace the containers with something else?
A simpler, albeit less elegant, solution would be a C-style allocation callback.
The standard solution is to use std::pmr::vector etc. which are just aliases for std::vector<T, std::pmr::polymorphic_allocator<T>> and so on. It truly is the solution to the C++ allocator nonsense. The std::pmr::polymorphic_allocator accepts a std::pmr::memory_resource* which does the allocation through its protected virtual do_allocate, do_deallocate and do_is_equal. Override those 3, you have full polymorphic allocation, i.e. per object non-typed differences in allocation strategy.
The C++11 impl is here, provided by the guy who gave the talk that made me understand it: here (1hr). If you do want to adopt it (my preference), I would definitely recommend going the abseil strategy of just aliasing the actual type if it is available.
C callback would work, wouldn't particularly make me happy tho 😄 .
I'm working on a first attempt this weekend.
Yea. I'm using his C++11 impl of pmr. I'll have to figure out the best way to switch to the c++17 one if that's available