WebRTC源码分析-线程基础之线程基本功能

目录

前言

Thread对象的创建

线程的启动

线程的终止

线程的sleep,join以及阻塞权限

获取当前线程对象 && 判断是否是当前线程

线程的Wrap

总结


前言

如之前的总述文章所述,rtc::Thread类封装了WebRTC中线程的一般功能,比如设置线程名称,启动线程执行用户代码,线程的join,sleep,run,stop等方法;同时也提供了线程内部的消息循环,以及线程之间以同步、异步方式投递消息,同步方式在目标线程执行方法并返回结果等线程之间交互的方式;另外,每个线程均持有SocketServer类成员对象,该类实现了IO多路复用功能。

本文将针对rtc::Thread类所提供的基础线程功能来进行介绍,Thread类在rtc_base目录下的thread.h中声明,如下(删除了其他非线程基础功能的API,其他的API将于另外的文章中分析):

class RTC_LOCKABLE Thread : public MessageQueue {
public:
  // 线程的构造,析构
  Thread();
  explicit Thread(SocketServer* ss);
  explicit Thread(std::unique_ptr<SocketServer> ss);
  Thread(SocketServer* ss, bool do_init);
  Thread(std::unique_ptr<SocketServer> ss, bool do_init);
  ~Thread() override;
  static std::unique_ptr<Thread> CreateWithSocketServer();
  static std::unique_ptr<Thread> Create();

  // 线程的名字
  const std::string& name() const { return name_; }
  bool SetName(const std::string& name, const void* obj);

  // 当前线程
  static Thread* Current();
  bool IsCurrent() const;

  // 阻塞权限
  bool SetAllowBlockingCalls(bool allow);
  static void AssertBlockingIsAllowedOnCurrentThread();

  // 休眠
  static bool SleepMs(int millis);

  // 线程的启动与停止
  bool Start(Runnable* runnable = nullptr);
  virtual void Stop();
  virtual void Run();

  // 线程的Wrap
  bool IsOwned();
  bool WrapCurrent();
  void UnwrapCurrent();

 protected:
  void SafeWrapCurrent();

  // 等待线程结束
  void Join();

 private:
#if defined(WEBRTC_WIN)
  static DWORD WINAPI PreRun(LPVOID context);
#else
  static void* PreRun(void* pv);
#endif

  bool WrapCurrentWithThreadManager(ThreadManager* thread_manager,
                                    bool need_synchronize_access);
  bool IsRunning();

  std::string name_;

#if defined(WEBRTC_POSIX)
  pthread_t thread_ = 0;
#endif
#if defined(WEBRTC_WIN)
  HANDLE thread_ = nullptr;
  DWORD thread_id_ = 0;
#endif
  bool owned_ = true;

  friend class ThreadManager;

  RTC_DISALLOW_COPY_AND_ASSIGN(Thread);
};

Thread对象的创建

创建Thread对象的构造方法有5个,如下源码所示:

// DEPRECATED.
Thread::Thread() : Thread(SocketServer::CreateDefault()) {}

Thread::Thread(SocketServer* ss) : Thread(ss, /*do_init=*/true) {}

Thread::Thread(std::unique_ptr<SocketServer> ss)
    : Thread(std::move(ss), /*do_init=*/true) {}

Thread::Thread(SocketServer* ss, bool do_init)
    : MessageQueue(ss, /*do_init=*/false) {
  SetName("Thread", this);  // default name
  if (do_init) {
    DoInit();
  }
}

Thread::Thread(std::unique_ptr<SocketServer> ss, bool do_init)
    : MessageQueue(std::move(ss), false) {
  SetName("Thread", this);  // default name
  if (do_init) {
    DoInit();
  }
}

需要注意的是:

  1. 默认构造函数Thread()被标注为DEPRECATED,原因是其对外隐藏了一个事实,即Thread对象是否与一个SocketServer对象绑定。实际上该默认构造会创建一个SocketServer对象绑定到Thread对象,而大多数的应用场景下Thread对象不需要SocketServer。因此,源码的注释中告知使用Create*的两个静态方法来创建Thread对象。

  2. 两个explicit声明的单个入参的构造函数,分别会调用含有两个入参的构造函数,唯一的区别在于入参是SocketServer*指针还是智能指针std::unique_ptr<SocketServer>类型。如果是后者那么需要使用std::move来转移SocketServer的拥有权(std::move是一个c++11的语法糖,实现了移动语义,详细的分析可以见博客C++11 std::move和std::forward)。但无论是哪个构造函数,都需要做以下三件事:
    1) 构造父对象MQ。由于Thread继承于MessageQueue对象,因此首先构造MQ父对象,调用MQ的构造函数,传入SocketServer对象指针以及布尔值false。此处传入的SocketServer不允许为空,否则触发断言;此处传入布尔值false,告知MQ的构造函数 “DoInit()方法你就不要调用了,我会在外面调用的”。
    2) 调用DoInit(),该方法应该在Thread构造中调用,而非在MQ的构造中调用,为什么要这么做?该方法源码如下:我们会发现该方法将MQ的初始化标志置为true,并且将自身纳入MQ管理类的管理列表中。如果DoInit在MQ构造中调用,意味着MQ构造后,Thread对象的指针已经暴露于外(被MQ管理类对象持有),此时Thread对象并未完全构建完成,其虚表vtable还未完全建立。这势必会导致Thread的对象还未构造完成时,就可能会被外部使用(在别的线程中通过MessageQueueManager访问该对象)的风险。为了规避这样的竞太条件,因此,需要给MQ的构造传入false,并在Thread构造中调用DoInit()。

void MessageQueue::DoInit() {
  if (fInitialized_) {
    return;
  }

  fInitialized_ = true;
  MessageQueueManager::Add(this);
}

3)调用SetName()方法为Thread对象命名。源码如下,需要明白的一点是,该方法的执行必须在线程启动之前,否则会触发断言。并且,由于是在线程启动之前执行,该方法仅仅是给用户层的Thread对象成员name_赋值而已,系统内核中线程相关的结构体还未建立,因此,也就无法将该名称设置到内核。只有当线程启动后,才能进一步的将name_设置到线程的内核结构体中去。一般默认名称形如"Thread 0x04EFF758"。

bool Thread::SetName(const std::string& name, const void* obj) {
  RTC_DCHECK(!IsRunning());

  name_ = name;
  if (obj) {
    // The %p specifier typically produce at most 16 hex digits, possibly with a
    // 0x prefix. But format is implementation defined, so add some margin.
    char buf[30];
    snprintf(buf, sizeof(buf), " 0x%p", obj);
    name_ += buf;
  }
  return true;
}

两个静态Create*方法来创建Thread对象。

  • Thread::Create():给Thread构造传入的是NullSocketServer对象,该对象不持有真正的Socket,使得创建的Thread无法处理网络IO,但可以运行消息循环,可以处理线程间消息投递。WebRTC中工作线程worker_thread_默认使用该方法创建;
  • Thread::CreateWithSocketServer():给Thread构造传入PhysicalSocketServer对象,该对象持有平台相关的Socket对象,使得Thread能处理网络IO,当然,也可以处理线程间消息投递。WebRTC中网络线程network_thread_默认使用该方法创建。
std::unique_ptr<Thread> Thread::CreateWithSocketServer() {
  return std::unique_ptr<Thread>(new Thread(SocketServer::CreateDefault()));
}

std::unique_ptr<Thread> Thread::Create() {
  return std::unique_ptr<Thread>(
      new Thread(std::unique_ptr<SocketServer>(new NullSocketServer())));
}

线程的启动

线程启动相关的API为Start(),IsRunnning(),PreRun(),结构体ThreadInit,类Runable,平台相关的线程启动函数CreateThread()以及pthread_create()。

  • Start() 方法是WebRTC中线程启动的标准方法,算法流程如下:断言,判断线程是否已经启动-->复位底层消息循环停止标志位-->确保ThreadManager对象的创建-->赋值结构体ThreadInit->平台相关的线程启动。
bool Thread::Start(Runnable* runnable) {
  // 测试环境下的断言,当前线程必须处于非运行状态,否则触发Fatal Error
  RTC_DCHECK(!IsRunning());

  // 如果线程处于运行状态则Start返回false
  if (IsRunning())
    return false;

  // 复位消息循环stop标志位
  Restart();  // reset IsQuitting() if the thread is being restarted

  // Make sure that ThreadManager is created on the main thread before
  // we start a new thread.
  // 确保ThreadManager在主线程中构建
  ThreadManager::Instance();
  
  // 线程对象Thread不是Wrap而来
  owned_ = true;

  // 赋值结构体ThreadInit
  ThreadInit* init = new ThreadInit;
  init->thread = this;
  init->runnable = runnable;

  // 平台相关代码,Windows系统下启动线程,使用CreateThread API
#if defined(WEBRTC_WIN)
  thread_ = CreateThread(nullptr, 0, PreRun, init, 0, &thread_id_);
  if (!thread_) {
    return false;
  }
  // 类Unix系统下启动线程,使用pthread库
#elif defined(WEBRTC_POSIX)
  pthread_attr_t attr;
  pthread_attr_init(&attr);
  int error_code = pthread_create(&thread_, &attr, PreRun, init);
  if (0 != error_code) {
    RTC_LOG(LS_ERROR) << "Unable to create pthread, error " << error_code;
    thread_ = 0;
    return false;
  }
  RTC_DCHECK(thread_);
#endif

  return true;
}
  • RTC_DCHECK 宏在debug模式下,被定义为RTC_CHECK,起到断言的作用(具体会专门写一篇文章来分析WebRTC中的断言);在非debug模式下,RTC_DCHECK被定义为RTC_EAT_STREAM_PARAMETERS,不论condition(ignored)是true or false,该宏定义的最后两行断言代码都不会被执行,而宏定义的第二行(true ? true : ((void)(ignored), true))是为了不让编译器报ignored未被使用的警告。
// The RTC_DCHECK macro is equivalent to RTC_CHECK except that it only generates
// code in debug builds. It does reference the condition parameter in all cases,
// though, so callers won't risk getting warnings about unused variables.
#if RTC_DCHECK_IS_ON
#define RTC_DCHECK(condition) RTC_CHECK(condition)
#else
#define RTC_DCHECK(condition) RTC_EAT_STREAM_PARAMETERS(condition)
#endif

#define RTC_EAT_STREAM_PARAMETERS(ignored)                        \
  (true ? true : ((void)(ignored), true))                         \
      ? static_cast<void>(0)                                      \
      : rtc::webrtc_checks_impl::FatalLogCall<false>("", 0, "") & \
            rtc::webrtc_checks_impl::LogStreamer<>()
  • IsRunning() 代码如下。在Thread类声明中,Windows环境下有两个值来表征线程,句柄类型的HWND thread_被初始化为nullptr,整数类型的DWORD thread_id_ 被初始化为0; 类Unix系统中只有pthread_t thread_一个变量来表征线程,初始化为0。判断线程是否为Running状态,只要判断thread_是否为有效值即可,因为在Start()方法中启动线程时,会调用平台相关的方法给该参数赋有效值。
bool Thread::IsRunning() {
#if defined(WEBRTC_WIN)
  return thread_ != nullptr;
#elif defined(WEBRTC_POSIX)
  return thread_ != 0;
#endif
}
  • Restart() 是父类MQ的方法, 作用是原子操作将stop_置为0,表征该MQ未停止。
void MessageQueue::Restart() {
  AtomicOps::ReleaseStore(&stop_, 0);
}
  • 初始化ThreadManager 此处即调用ThreadManager::instance()方法,确保ThreadManager在主线程中初始化。另外owned_设置为true,表征Thread对象是常规的Start()方法启用的,而非Wrap而来。
  • ThreadInit 结构体用于平台相关的启动线程函数的入参,定义如下:
  struct ThreadInit {
    Thread* thread;
    Runnable* runnable;
  };

其中Runnable用来承载用户需要执行的代码,用于继承Runnable并实现Run方法即可。

class Runnable {
 public:
  virtual ~Runnable() {}
  virtual void Run(Thread* thread) = 0;
 protected:
  Runnable() {}
 private:
  RTC_DISALLOW_COPY_AND_ASSIGN(Runnable);
};
  • 启动线程:
    在Windows上调用CreateThread API来启动线程,当该方法执行成功时,将返回线程的句柄给thread_,线程的id给thread_id_,并在该线程上执行PreRun()方法,init为上述ThreadInit对象,其作为入参传递给PreRun()方法。
#if defined(WEBRTC_WIN)
  thread_ = CreateThread(nullptr, 0, PreRun, init, 0, &thread_id_);
  if (!thread_) {
    return false;
  }

在类Unix系统上,使用pthread库的pthread_create() API来启用线程,方法执行成功对pthread thread_的成员赋值,类似的将在新线程上执行PreRun()方法,并将ThreadInit结构的对象init作为其入参传入。

#elif defined(WEBRTC_POSIX)
  pthread_attr_t attr;
  pthread_attr_init(&attr);
  int error_code = pthread_create(&thread_, &attr, PreRun, init);
  if (0 != error_code) {
    RTC_LOG(LS_ERROR) << "Unable to create pthread, error " << error_code;
    thread_ = 0;
    return false;
  }
  RTC_DCHECK(thread_);
#endif
  • PreRun() 方法是在新启用的线程上执行的代码,不同平台下该函数声明上略有差别,实质上入参是相同的ThreadInit对象。本函数是本文最重要的地方,涉及到了ThreadManager管理Thread类的秘密,涉及到了用户代码如何在新线程上被执行,线程内部的消息循环是如何被运行起来的。
    函数内部的执行逻辑写在代码注释上,特殊需要拆解的地方后续说明,源码如下:
#if defined(WEBRTC_WIN)
DWORD WINAPI Thread::PreRun(LPVOID pv) {
#else
void* Thread::PreRun(void* pv) {
#endif
  // 如前文所述,ThreadInit作为入参传给PreRun方法。
  ThreadInit* init = static_cast<ThreadInit*>(pv);
  // 将新创建的Thread对象纳入管理,与当前线程进行绑定。
  ThreadManager::Instance()->SetCurrentThread(init->thread);
  // 为线程设置名称,该方法会调用平台相关的API给线程内核结构体赋值上该线程的名称。
  rtc::SetCurrentThreadName(init->thread->name_.c_str());
 // 如果是MAC系统,通过pool对象的创建和析构来使用oc的自动释放池技术,进行内存回收。
#if defined(WEBRTC_MAC)
  ScopedAutoReleasePool pool;
#endif
  // 如果用户需要执行自己的代码,那么就会继承Runnable并实现Run方法,此时,正是执行
  // 用户代码的时刻;否则,将执行Thread的默认Run方法。
  if (init->runnable) {
    init->runnable->Run(init->thread);
  } else {
    init->thread->Run();
  }
  // 到此,线程主要的活儿已干完,以下做清理工作
  // 将线程对象与当前线程解绑
  ThreadManager::Instance()->SetCurrentThread(nullptr);
  // 释放ThreadInit对象
  delete init;
  // 返回,记得pool局部对象的释放会触发MAC系统下的自动释放池进行内存回收。
#ifdef WEBRTC_WIN
  return 0;
#else
  return nullptr;
#endif
}

上述代码需要特殊关注点在于:
1)新线程上PreRun()方法执行起来后,ThreadManager立马将当前线程与该Thread对象关联起来,纳入管理之中,当PreRun()方法要执行完毕了,又将当前线程与Thread对象解绑,毕竟该方法退出后,线程就会停止。
2)为当前线程设置名称:前文已经知道在Thread对象构造时,会给Thread的命名字段name_赋值形如"Thread 0x04EFF758"的名称,但并未调用系统相关的API给线程内核对象相关的字段赋值,因为那个时候线程还未启动,线程在系统内核中还没有相应的对象存在呢。此时,需要做这个工作。如下就是rtc::SetCurrentThreadName(init->thread->name_.c_str()) 方法的源码:

void SetCurrentThreadName(const char* name) {
#if defined(WEBRTC_WIN)
  struct {
    DWORD dwType;
    LPCSTR szName;
    DWORD dwThreadID;
    DWORD dwFlags;
  } threadname_info = {0x1000, name, static_cast<DWORD>(-1), 0};

  __try {
    ::RaiseException(0x406D1388, 0, sizeof(threadname_info) / sizeof(DWORD),
                     reinterpret_cast<ULONG_PTR*>(&threadname_info));
  } __except (EXCEPTION_EXECUTE_HANDLER) {  // NOLINT
  }
#elif defined(WEBRTC_LINUX) || defined(WEBRTC_ANDROID)
  prctl(PR_SET_NAME, reinterpret_cast<unsigned long>(name));  // NOLINT
#elif defined(WEBRTC_MAC) || defined(WEBRTC_IOS)
  pthread_setname_np(name);
#endif
}

3)作为Mac系统上的特例,使用了objc的自动释放池技术来管理内存,实际上就是通过局部变量ScopedAutoReleasePool pool的构造以及PreRun函数结束时该对象的析构来调用objc的objc_autoreleasePoolPush()和objc_autoreleasePoolPop()进行内存释放。至于其原理嘛,可以看此篇博客:自动释放池的前世今生 ---- 深入解析 Autoreleasepool

#if defined(WEBRTC_MAC)
#include "rtc_base/system/cocoa_threading.h"

extern "C" {
void* objc_autoreleasePoolPush(void);
void objc_autoreleasePoolPop(void* pool);
}

class ScopedAutoReleasePool {
 public:
  ScopedAutoReleasePool() : pool_(objc_autoreleasePoolPush()) {}
  ~ScopedAutoReleasePool() { objc_autoreleasePoolPop(pool_); }
 private:
  void* const pool_;
};
#endif

4)如果用户并不想执行自己的代码,即不给Start方法传入Runnabel对象,那么Thread对象提供了默认的Run()方法在新线程上执行,该方法源码如下。本文不展开去叙述ProcessMessages(kForever)是如何运作的,因为这属于消息循环的内容,会在下一篇文章中分析,此处只要知道,如果用户不运行自己的代码干自己的活,那么默认的方式就是启动了一个消息循环不停地在此执行。

void Thread::Run() {
  ProcessMessages(kForever);
}

bool Thread::ProcessMessages(int cmsLoop) {
  // Using ProcessMessages with a custom clock for testing and a time greater
  // than 0 doesn't work, since it's not guaranteed to advance the custom
  // clock's time, and may get stuck in an infinite loop.
  RTC_DCHECK(GetClockForTesting() == nullptr || cmsLoop == 0 ||
             cmsLoop == kForever);
  int64_t msEnd = (kForever == cmsLoop) ? 0 : TimeAfter(cmsLoop);
  int cmsNext = cmsLoop;

  while (true) {
#if defined(WEBRTC_MAC)
    ScopedAutoReleasePool pool;
#endif
    Message msg;
    if (!Get(&msg, cmsNext))
      return !IsQuitting();
    Dispatch(&msg);

    if (cmsLoop != kForever) {
      cmsNext = static_cast<int>(TimeUntil(msEnd));
      if (cmsNext < 0)
        return true;
    }
  }
}

线程的终止

停止一个线程,可以通过调用线程的Thread.Stop()方法来实施,但千万不能在当前线程上调用该方法来终止自己。MQ的Quit()方法会在介绍消息循环时来详细解释,此处作用就是停止线程消息循环。Join()方法在后面介绍,此处作用是阻塞地等待目标线程终止,因此,Stop函数一般会阻塞当前线程。

void Thread::Stop() {
  MessageQueue::Quit();
  Join();
}

线程的sleep,join以及阻塞权限

Thread类中bool blocking_calls_allowed_字段控制着在该线程是否可以运行阻塞,等待操作,比如静态方法SleepMs,线程的Join。
-SleepMs() 方法提供了线程休眠功能,方法中先对当前线程是否允许阻塞进行断言,然后在Windows上调用Windows API Sleep()方法对当前线程休眠,类Unix系统上使用nanosleep()系统调用进行休眠。

bool Thread::SleepMs(int milliseconds) {
  // 断言当前线程是否允许阻塞
  AssertBlockingIsAllowedOnCurrentThread();
 //调用不同平台下的线程休眠函数进行休眠
#if defined(WEBRTC_WIN)
  ::Sleep(milliseconds);
  return true;
#else
  // POSIX has both a usleep() and a nanosleep(), but the former is deprecated,
  // so we use nanosleep() even though it has greater precision than necessary.
  struct timespec ts;
  ts.tv_sec = milliseconds / 1000;
  ts.tv_nsec = (milliseconds % 1000) * 1000000;
  int ret = nanosleep(&ts, nullptr);
  if (ret != 0) {
    RTC_LOG_ERR(LS_WARNING) << "nanosleep() returning early";
    return false;
  }
  return true;
#endif
}

此处我们看一下这个是否允许阻塞的函数实现,该方法由NDEBUG宏来控制,意味着在debug模式下才会起作用,而非debug模式下,该函数什么也不做。在debug模式,如果当前线程关联了Thread对象,并且其Thread.blocking_calls_allowed_字段设置为false,表示不允许该线程阻塞的情况下,就会触发断言。即在此Thread所关联的线程中调用SleepMs()方法会触发断言,从而终止程序的运行。

// static
void Thread::AssertBlockingIsAllowedOnCurrentThread() {
#if !defined(NDEBUG)
  Thread* current = Thread::Current();
  RTC_DCHECK(!current || current->blocking_calls_allowed_);
#endif
}

另外,Thread也提供了一个可以设置blocking_calls_allowed_字段的方法SetAllowBlockingCalls()

bool Thread::SetAllowBlockingCalls(bool allow) {
  RTC_DCHECK(IsCurrent());
  bool previous = blocking_calls_allowed_;
  blocking_calls_allowed_ = allow;
  return previous;
}
  • Join()
    该方法用于某个线程中等待另外一个Thread所表征的线程停止。算法流程如源码注释:
void Thread::Join() {
  // 判断等待的线程对象Thread所表征的线程是否已经停止,若已停止了,那么就不需要等待了,直接返回吧
  if (!IsRunning())
    return;
  // 断言是否是在当前线程调用自己的Join造成自己等待自己
  RTC_DCHECK(!IsCurrent());
  // 判断当前线程是否具有阻塞权限,如无,则打印警告,但是并没有进行断言
  if (Current() && !Current()->blocking_calls_allowed_) {
    RTC_LOG(LS_WARNING) << "Waiting for the thread to join, "
                        << "but blocking calls have been disallowed";
  }

  // 平台相关的实现

  // Windows平台下调用WaitForSingleObject() API进行等待
#if defined(WEBRTC_WIN)
  RTC_DCHECK(thread_ != nullptr);
  // 等待目标线程终止 
  WaitForSingleObject(thread_, INFINITE);
  // 关闭线程句柄
  CloseHandle(thread_);
  // 成员复位
  thread_ = nullptr;
  thread_id_ = 0;

  // 类Unix系统下调用pthread库的pthread_join()方法进行等待
#elif defined(WEBRTC_POSIX)
  // 等待目标线程终止 
  pthread_join(thread_, nullptr);
  // 成员复位
  thread_ = 0;
#endif
}

获取当前线程对象 && 判断是否是当前线程

获取当前线程Thread对象的方式直接复用了ThreadManager的CurrentThread()方法,若当前线程没有关联相关的Thread对象,那么返回空指针,若当前线程是创建ThreadManager对象的线程,也即主线程,那么如果主线程没有关联Thread对象,且没有定义NO_MAIN_THREAD_WRAPPING,则会给主线程Wrap一个Thread对象。

Thread* Thread::Current() {
  ThreadManager* manager = ThreadManager::Instance();
  Thread* thread = manager->CurrentThread();

#ifndef NO_MAIN_THREAD_WRAPPING
  // Only autowrap the thread which instantiated the ThreadManager.
  if (!thread && manager->IsMainThread()) {
    thread = new Thread(SocketServer::CreateDefault());
    thread->WrapCurrentWithThreadManager(manager, true);
  }
#endif
  return thread;
}

判断Thread对象是否是当前线程关联的Thread,也很简单,源码如下:

bool Thread::IsCurrent() const {
  return ThreadManager::Instance()->CurrentThread() == this;
}

线程的Wrap

Thread中Wrap相关的API有4个,如下源码所示。在WebRTC源码分析-线程基础之线程管理一文中已经解析过Wrap相关的函数,此处不再展开表述。Wrap函数主要用于如下情形:线程启动不是由标准的WebRTC启动方式实施,即不是通过调用Thread.Start()方法启动。那么,此刻线程没有与一个Thread对象相关联,那么Wrap就是干这个事,将一个线程与一个Thread对象关联起来。具体而言,有如下3件事需要做:

  • 获取当前线程的句柄,并赋值给Thread.thread_成员;
  • 将Thread.owned_成员设置为false,表示该线程对象是Wrap而来;
  • 将Thread对象与当前线程关联起来,纳入ThreadManager的管理之中。
bool WrapCurrent();
void UnwrapCurrent();
void SafeWrapCurrent();
bool WrapCurrentWithThreadManager(ThreadManager* thread_manager,
                                    bool need_synchronize_access);

总结

本文阐述了rtc::Thread类所提供的基础线程功能,分别从Thread对象的创建,新线程的启动与终止,线程阻塞权限以及线程阻塞相关的函数SleepMs、Join,获取当前线程、如何判断代码是否在当前线程中执行,线程的Wrap等几个方面进行了分析。以下是需要再重点回顾的几个点:

  • Thread类中线程相关的功能是在封装了平台相关API的基础上实现的,在Windows系统上是通过Windows API提供,在类Unix系统上是通过pthread库提供。比如Win上创建线程CreateThread(),类Unix上相应为pthread_create();Win上休眠Sleep(),类Unix上是nanosleep()系统调用,非pthread库功能;Win上线程join使用WaitForSingleObject(),类Unix上使用pthread库的pthread_join();
  • Thread对象的构造时有个需要注意的点,那就是DoInit()方法需要Thread构造函数中被调用,否则会引发竞太条件。
  • Thread.Start()方法以及Thread.PreRun()方法是本文重点,是WebRTC中启动线程的标准流程。
  • Thread类提供了线程是否允许阻塞的权限设置,由成员Thread.blocking_calls_allowed_来控制,Thread中引发线程阻塞的函数,如SleepMs,Join,Send等都会先进行权限检查,要么打印警告日志,要么触发断言。
  • Thread类的Wrap函数族提供了非标准方式启动的线程纳入ThreadManager管理的额外方式。
  • 14
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
### 回答1: webrtc-qt-example是一个基于Qt框架开发的WebRTC示例项目。 WebRTC是一种开源的实时通信技术,能够支持音频、视频和数据的实时传输。它通过浏览器之间的端对端连接,实现了高质量的实时通信。 webrtc-qt-example的目的是展示如何使用Qt进行WebRTC开发。Qt是一套跨平台的C++应用程序开发框架,它提供了丰富的工具和库,使开发者能够快速构建可靠的应用程序。 这个示例项目提供了一些基本的功能和界面,使开发者能够了解和学习如何将WebRTC集成到Qt应用程序中。它包含了常见的WebRTC功能,如媒体流捕获、媒体流传输、信令交换等。 通过webrtc-qt-example,开发者可以学习到如何使用Qt的多媒体模块来捕获音频、视频和媒体设备。同时,也可以学习到如何使用Qt的网络模块来进行实时信令交换和流传输。 这个示例项目还提供了一些简单的界面,方便开发者进行测试和调试。开发者可以通过该界面实现与其他WebRTC应用的通信,例如建立视频通话、音频通话等。 总之,webrtc-qt-example是一个非常实用的示例项目,可以帮助开发者快速上手并掌握WebRTC在Qt中的开发。 ### 回答2: webrtc-qt-example是一个基于Qt框架的WebRTC示例应用程序。WebRTC是一种开源项目,它提供了在浏览器之间进行实时通信的能力,包括视频和音频的传输。而webrtc-qt-example则是将这种技术集成到Qt应用程序中的一个示例。 在webrtc-qt-example中,它使用了Qt的多媒体框架和WebRTC提供的API来实现音视频的传输和显示。通过使用WebRTC的API,webrtc-qt-example可以建立点对点的连接,进行音频和视频的实时传输。 webrtc-qt-example中的代码结构清晰,易于理解和扩展。它提供了一些基本的功能,如建立连接、发送和接收音视频流、呼叫取消等。开发者可以根据自己的需求来对这些功能进行定制和扩展。 此外,webrtc-qt-example还支持一些高级特性,如媒体设备的选择、音视频的编码和解码等。开发者可以通过修改代码来选择不同的媒体设备,并且可以使用不同的编码和解码算法来满足自己的需求。 总之,webrtc-qt-example是一个很棒的WebRTC示例应用程序,它可以帮助开发者快速了解和使用WebRTC技术。无论是为了实现实时视频通话、视频会议还是其他需要音视频传输的应用场景,webrtc-qt-example都提供了一个良好的起点,帮助开发者快速上手并实现自己的需求。 ### 回答3: webrtc-qt-example是一个基于Qt框架和WebRTC技术的示例应用。WebRTC是一种用于在Web浏览器上实现实时通信的开源项目,它提供了一套丰富的API和协议,可以实现音视频通话、数据传输以及屏幕共享等功能。 webrtc-qt-example利用Qt框架提供的跨平台能力,结合WebRTC技术,展示了在Qt应用中如何实现实时通信功能。这个示例应用具有以下特点和功能: 1. 界面友好:webrtc-qt-example使用Qt的GUI绘制工具,具有美观、直观的用户界面,便于用户操作和使用。 2. 实时通信:webrtc-qt-example内置了WebRTC的音视频通信功能,可以实现实时的语音和视频通话,支持两个或多个用户之间的通信。 3. 数据传输:除了音视频通话,webrtc-qt-example还支持在通话中传输数据。可以通过编写代码,实现实时文本传输或共享文件等功能。 4. 屏幕共享:webrtc-qt-example还支持屏幕共享功能,可以将自己的屏幕内容分享给其他用户,实现远程协助或在线教育等应用场景。 通过webrtc-qt-example的学习和实践,开发者可以了解并深入理解WebRTC技术的使用方法,以及在Qt框架中的应用。同时,借助webrtc-qt-example提供的示例代码和API文档,开发者可以进一步开发出更加复杂和功能丰富的实时通信应用,满足不同领域的需求。 总之,webrtc-qt-example是一个基于Qt框架和WebRTC技术的示例应用,具备实时音视频通话、数据传输和屏幕共享等功能,适用于开发者学习、实践和开发基于WebRTC的实时通信应用程序。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值