webrtc Thread 和 TaskQueue 的 应用和思考

webrtc Thread 和 TaskQueue 的 应用和思考

Thread

#include "rtc_base/thread.h"

void FunctionToRunOnThread() {
    // Your threaded logic here.
    printf("Function running on the thread!\n");
}

int main() {
    rtc::Thread* thread = rtc::Thread::Create().release();
    thread->Start();

    // Send a task to the thread.
    thread->Invoke<void>(RTC_FROM_HERE, &FunctionToRunOnThread);

    // Cleanup.
    thread->Stop();
    delete thread;

    return 0;
}

为什么要在Create 后调用release：rtc::Thread* thread = rtc::Thread::Create().release();

这种写法的目的是获取std::unique_ptr管理的原始指针，并确保std::unique_ptr不会在作用域结束后自动删除它。

当你调用rtc::Thread::Create()时，这个函数返回一个std::unique_ptr对象。这个std::unique_ptr对象拥有一个rtc::Thread的实例，当这个std::unique_ptr对象超出作用域或被销毁时，它会自动删除这个rtc::Thread实例。

当你调用release()方法时，你实际上是在告诉std::unique_ptr放弃对rtc::Thread的所有权。这意味着std::unique_ptr不再拥有这个对象，并且在std::unique_ptr销毁时不会删除它。这就允许你手动管理这个对象的生命周期。

** 所以 release 是 std::unique_ptr 的方法。**

TaskQueue

#include "rtc_base/task_queue.h"

void FunctionToRunOnQueue() {
    // Your task logic here.
    printf("Function running on the task queue!\n");
}

int main() {
    rtc::TaskQueue task_queue("MyTaskQueue");

    // Post a task to the queue.
    task_queue.PostTask(RTC_FROM_HERE, &FunctionToRunOnQueue);

    // The task queue will automatically handle the task. 
    // For the sake of this example, just wait a bit to let the task run.
    rtc::Thread::Current()->SleepMs(100);

    return 0;
}

RTC_FROM_HERE 是 WebRTC 代码库中用于标识代码位置的宏。它通常与日志、断言和任务调度等功能一起使用，以提供源代码中的文件名和行号信息。

例如，当你在 WebRTC 中遇到一个断言失败或者想要追踪一个特定的日志事件，RTC_FROM_HERE 会提供一个表示代码位置的rtc::Location对象，这样你可以知道是哪个文件的哪一行产生了这个事件或错误。

它的定义大致如下：

#define RTC_FROM_HERE rtc::Location(__FILE__, __LINE__)

webrtc::Thread 和 webrtc::TaskQueue 为什么不单独编译成so 给webrtc使用 而将 源码集成到webrtc 中，他们不是解耦的吗？

将webrtc::Thread和webrtc::TaskQueue直接集成到 WebRTC 源码中，而不是编译为单独的 .so (shared object) 文件或库，是基于几个原因的决策：

1. 紧密集成: 尽管webrtc::Thread和webrtc::TaskQueue作为组件是相对独立的，但它们与 WebRTC 的其他部分有着紧密的交互和依赖关系。将它们与核心代码紧密集成可以确保更好的性能和优化。

2. 编译和链接优化: 将所有组件编译到一个单一的二进制文件中允许编译器进行更多的跨模块优化。这可能会导致更快的代码和更小的二进制大小。

3. 简化部署和分发: 不需要管理、分发和链接多个.so文件可以简化应用程序的部署和分发。此外，这可以确保版本兼容性，因为所有组件都是从同一源码树构建的。

4. 避免 ABI (Application Binary Interface) 的问题: ABI 是二进制代码如何在运行时调用和使用的一个规范。不同的编译器、编译器版本或编译器标志可能会导致不同的 ABI。将所有东西编译到一个库中可以避免潜在的 ABI 兼容性问题。

5. 维护和开发效率: 在单一的代码库中工作可以简化开发流程，特别是当需要跨多个组件进行更改时。

6. 安全性: 将所有组件紧密集成可以确保一致的安全实践和策略。此外，避免加载外部.so文件还可以减少潜在的安全风险。