About the smart pointer of SRS.

[winlinvip]

Before any work addressing this issue, we need refine the shared ptr of SRS, which is used in RTMP shared message, GB sessions, and in future source objects.

Refer to Using C++11’s Smart Pointers, there are three varieties of smart pointers:

• Shared ptr: Akin to SrsSharedPtrMessage used for RTMP message, and SrsLazyObjectWrapper for GB28181.
• Weak ptr: No such ptr in SRS before 5.0 version. We can avoid this by removing any circle reference of pointer.
• Unique ptr: The corresponding ptr is SrsAutoFree that free the ptr in the local scope.

If we carefully design and limit the usage of smart ptr, such as no cycle link that means we do not need weak ptr, we can archive a simple and easy to maintain smart ptr for SRS. We also consider bellow features:

• Inheritance: Do not use inheritance with smart pointer, although we can write correct code, but it's complex to discuss.
• Comparing: Do not support comparing smart pointers, because we only need to manage the memory automatically.
• make_shared: Do not support this helper function, because we do not consider performance issue by new operator.
• shared_from_this: Do not support this helper template, because we do not need this feature.
• make_unique: Do not support this, because we allow naked new operator, and carefully code review is required.

Again, we don't want to switch to C++11 because I think the modern C++ 11/14/17/20 is really a horrible thing that does not fix anything, but introduces a lot of bad grammar sugar. We do not want any grammar sugar, which is very harmful for communication. We have experienced a lot of disaster of smart pointers and sugars, so we want to keep the usage very simple:

1. No grammar sugar: No weak ptr, no make shared, no make unique, no inheritance, no comparing, no circle reference, no C++11/14/17/20/22 etc.
2. Follow the C++ standard API if any API is really required, do not invent new wheels, no new functions and names.
3. Carefully code review, programmer should take responsibility for code and memory issues.

In the other hand, we should not reinvent wheels especially for smart ptr, so we must use almost the same API of C++ standard library. That is why we should learn from C++11 and refactor the similar smart ptrs in SRS.

Smart pointers might seem simple when they’re just about memory management, but when you delve into inheritance, copying, comparison, performance, circular references, pointer conversion, creation, and the purism of "no naked new", their capabilities become significantly richer. In reality, the main issues with C++ programs stem from programmers messing around, and this purism along with various syntactic sugar makes it hard to notice when they are.

Most problems can be addressed with something as straightforward as an AK47, yet there's an obsession with acquiring more advanced weaponry, which leads to a situation where, on the battlefield, you can’t even fire a shot due to jams and blowbacks. This is because it’s very hard to spot when programmers are messing about in companies, with large amounts of code being submitted, the usage of various new features, and tight deadlines.

The true gates of hell in C++ are not the limited old features of C, but its plethora of new features.

Change log:

• Use shared ptr and used in GB28181
• Use shared ptr in RTC TCP connection
• SmartPtr: Support shared ptr for SRT source.
• SmartPtr: Support shared ptr for RTC source.
• SmartPtr: Support shared ptr for live source.
• SmartPtr: Support load test for source by srs-bench
• SmartPtr: Fix SRT source memory leaking.
• UniquePtr: Support SrsUniquePtr to replace SrsAutoFree.

To verify this issue, start 1k clients over and over, note that we sleep for a while for SRS to cleanup sources:

cd srs/trunk/3rdparty/srs-bench
make
for ((i=0;;i++)); do 
  ./objs/srs_bench -sfu=live -pr=rtmp://localhost/live${i}/stream -sn=1000 -cap=true; 
  sleep 10; 
done

Note: We support benchmark RTMP, SRT, WHIP protocols.

Before v5.0.213, the RES of memory continue to growing:

docker run --name srs --rm -it -p 1935:1935 ossrs/srs:v5.0.205

Check the RES by top, which is the actually used memory:

docker exec -it srs top
#  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                                                                                          
#    1 root      20   0 2696388 273144  10624 S  24.7   3.4   0:35.64 srs 

The memory should never continue growing for v5.0.213 or later version.

TRANS_BY_GPT4