Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AllocatorAwareContainer #37

Open
breese opened this issue Sep 28, 2019 · 4 comments
Open

AllocatorAwareContainer #37

breese opened this issue Sep 28, 2019 · 4 comments

Comments

@breese
Copy link
Owner

breese commented Sep 28, 2019

From #35

An Allocator doesn't have to be default constructible or stateless. All functions should accept an allocator instance, const Allocator& a. You can default this to an instance of Allocator() but users who use allocators where this is not an option, can supply the appropriate instance.

@breese
Copy link
Owner Author

breese commented Sep 28, 2019

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.

@vinipsmaker
Copy link
Contributor

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.

@breese
Copy link
Owner Author

breese commented Sep 29, 2019

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?

@vinipsmaker
Copy link
Contributor

vinipsmaker commented Sep 29, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants