Open breese opened 4 years ago
I did look into making dynamic::variable
meet the AllocatorAwareContainer requirements, but ran into problems making the underlying discriminating union (small_union
) allocator-aware.
The challenge is that small_union
uses in-place storage (like std::variant
or boost::variant
) for some types, but heap storage for others. The reason for this was because dynamic::variable
is effectively a tree whose node size depends on the size of the largest type, which could be an std:;string
with small-string optimization.
That said, I am open to alternative solutions, including replacing small_union
with a normal variant.
I'll use allocators in the future for a project as a form of resource control to mitigate DoS. This is a feature I'm interested in.
What I do care about is heap usage. If small_union
is using stack for small strings, that's acceptable to me as long as it uses the allocator when it tries to use the heap.
How do you mitigate DoS? Do you use an allocator with bounded memory for incoming requests, and then ignore the request, and possibly close the connection, when an std::bad_alloc
exception is thrown?
How do you mitigate DoS? Do you use an allocator with bounded memory for incoming requests, and then ignore the request, and possibly close the connection, when an
std::bad_alloc
exception is thrown?
Each connection will have its own stateful allocator object. If the resource usage exceeds the limit for that connection (std::bad_alloc
), I drop the connection. And the number of accepted connections is limited per running application instance.
Global objects that communicate with the internal pipeline are unbounded and will use the default implicit allocator.
From #35