THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
So that not save a raw pointer in vector or other containers.
1.2 Using factory creators instead of new
In order to force the smart ptr usage, the developer could add macro ENABLE_FACTORY_CREATOR to class
like:
If you add this macro to the class, then we could make sure the smart ptr is used for our class.
Block* block = new Block(xxxx); // compile error during build
Block block(xxx); // it is ok
std::shared_ptr<Block> block = Block::create_shared(xxxx); // it is ok
std::unique_ptr<Block> block = Block::create_unique(xxxx); // it is ok
1.3 Just return smart ptr not raw pointer
Sometimes we use C style code when write C++ code, especially for return value. Many of our code, return a raw pointer and then set the value to
the smart pointer. We could just return unique_ptr.
1.4 Could use smart pointer check nullable directly not need convert to raw pointer
Many developer use if (smart_pointer.get()) to check if the smart pointer is null, actually we could check the
smart pointer directly.
reference: https://en.cppreference.com/w/cpp/memory/shared_ptr/operator_bool
https://en.cppreference.com/w/cpp/memory/unique_ptr/operator_bool
1.5 Lock and Unlock
There are many lock and unlock code. Could not make sure that the lock is correctly released. Should use unique lock or lock guard. For example, in following example, the lock is conditionally locked by checking acquire_lock
...
also blocking the underline IO thread in bRPC. So that we should use the following way. PUT the request into a pthread thread pool and do the work in pthread like line 225.
5. Do Not Do Heavy Work in Deconstructor and Not Do Deconstructor Work in Close method
For example, if we do some close work in deconstructor, the dependend parent raw ptr may be released. it will core.
6. Never use std::thread to create thread too frequently
If create or destroy too frequently, jemalloc may not behavior very well. Sometimes crash. like this:
Should use thread pool or std future or promise to do this.
7. Never add enum definition in the middle of the existing thrift definition.
During upgrade, doris's policy is to upgrade BE and then upgrade FE to do rolling upgrade. If we add a enum definition in the middle of the Enum Type, then the id order
will be different between FE and BE. I will cause exception or core.
8. Print status not error code
If error status is returned when call some method failed. Do not only print error code or error message, you could just print status object. because status will print callstack, we could know
which line failed. For example, in compaction, we print the result status, like this code:
then we could get error stack, like this:
9. Do not use admin set config in regression test
Do not use admin set frontend config any more because it will modify FE's config. In github's workflow, the test is running in a single thread.
So that it is not a problem. But in daily test, the regression test is running in multiple threads. If we modify fe's config, it will affect other regression
test. The test case will fail.
10 Add log(fatal) before builtin unreachable()
builtin unreachable will trigger sigtrap signal, it is not very clear when in debug mode, should add log fatal before it and its core stack will be more clear.
https://github.com/apache/doris/pull/24101