-
Notifications
You must be signed in to change notification settings - Fork 380
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
Cascaded allocator #2113
base: master
Are you sure you want to change the base?
Cascaded allocator #2113
Conversation
Only read your description, please use std::vector, ACE_Vector is old and we don't want to use that anymore |
2. using instead of typedef
I have fixed these questions, Have I lefted any unfinished review issues ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok
I am busy with other things, review time on github is very limited, you will have to wait until me or someone else has time to do another review, I only did a high level review |
ok, thx :) |
ACE/ace/Malloc_T.h
Outdated
|
||
private: | ||
// Useful STL-style traits. | ||
using comb_alloc_type = ACE_Dynamic_Cached_Allocator<ACE_Null_Mutex>; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't this be ACE_LOCK?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there is no need because the nested allocator will be protected by container class api
…to cascadedAllocator not updated
2、make simple for statement at one line 3、add the pool_sum API for component transparency 4、move pool_depth API from INL file to source file for its complexity
2、modify the test case to use lock strategy, that will more likely find some compiling error than free lock
2、fix some code style
2、fix test function name
ACE/ace/Malloc_T.cpp
Outdated
this->hierarchy_.push_back(tmp); | ||
if (0 == this->hierarchy_.size()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
empty?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when push_back fails it will throw, maybe use std::unique_ptr?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These APIs have strong exception safety guarantee, so there is no need to use std::unique_ptr.
Is it true ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By the way, I can see the result of these calls to judge whether potential exceptions have occurred
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See https://en.cppreference.com/w/cpp/language/exceptions, push_back can throw, when it does the state of the std::vector is guaranteed at that moment, but it will not just return. The exception should go back to the caller to my idea, your allocator should not leak when push_back (or any operation it uses) throws
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
when using unique_ptr the check after the push_back seems invalid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have used std::unique_ptr for idiom in new commit
But for a vector of pointer, I think sdt::vector can keep strong exception guarantee.
If an exception is thrown (which can be due to Allocator::allocate() or element copy/move constructor/assignment), this > function has no effect ([strong exception guarantee]> (https://en.cppreference.com/w/cpp/language/exceptions#Exception_safety)).
Strong exception guarantee — If the function throws an exception, the state of the program is rolled back to the state > just before the function call (for example, [std::vector::push_back]>(https://en.cppreference.com/w/cpp/container/vector/push_back)).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, Your idea is right!
The APIs provide strong exception guarantee, but not Nothrow
I will delete the defence codes
…ly the first and last allocator has free chunks
ACE
has fixed-sizeACE*_Cached_Allocator
, but in some case the totaln_chunks
can't be determined easyly :(If the
ACE
framework has the ability to malloc fixed-size chunks 'infinitely' just likeACE_Malloc< ACE_MEM_POOL_1, ACE_LOCK >
for mallocing various-size chunks, that will be very useful!design
ACE_Dynamic_Cached_Allocator
notACE_Cached_Allocator
ACE_Vector<T>
to enable the flexibility of allocator hierarchy2 * n_chunks(upper level)
capacity