GStreamer如何保证探针回调正常响应避免程序阻塞死循环

首先明确：不存在你提到的可直接轮询“缓冲区是否流过指定pad”的专用API。GStreamer的pad本身是无状态流传输端点，不会留存缓冲区经过的历史标记，缓冲区流经pad时只会同步派发给注册的探针、推送到下游，处理完成后不会保留相关状态位供外部查询。

当前代码死锁的根本原因 #

如果阻塞轮询逻辑运行在GStreamer管道绑定的GLib主上下文线程、或者管道流处理线程上，sleep/g_usleep会直接阻塞探针回调的派发线程——pad探针回调本身就是在流线程/对应主上下文中执行的，线程被阻塞后回调永远没有触发机会，自然会陷入while死循环，提前加的1秒休眠不仅解决不了问题，反而会延长阻塞时间。

标准实现方案 #

不需要把业务逻辑塞到探针回调里，也不需要用忙等轮询，用GLib原生的线程同步机制就能实现逻辑集中、无死锁的校验，这也是GStreamer场景下处理这类同步等待的通用做法：

• 探针回调只做极轻量的同步标记，不执行业务逻辑、不做阻塞操作
• 用GMutex+GCond做线程间通知，替代忙等轮询
• 等待逻辑放在独立于GStreamer流线程/主循环的工作线程中，避免阻塞管道运行

修正后的参考实现 #

// 可放在全局或自定义上下文结构体中定义同步变量
GMutex buff_lock;
GCond buff_cond;
gboolean b_haveBuffer = FALSE;

static GstPadProbeReturn
have_buff( GstPad *pad, 
             GstPadProbeInfo* info,
             gpointer data)
{
    // 加锁修改标记+发通知，整个回调逻辑极短，不阻塞流线程
    g_mutex_lock(&buff_lock);
    b_haveBuffer = TRUE;
    g_cond_signal(&buff_cond);
    g_mutex_unlock(&buff_lock);

    // 触发一次后自动移除探针，不需要后续手动调用remove_probe
    return GST_PAD_PROBE_REMOVE;
}


void loop_run()
{  
  if(reattach)
  { 
     // 完成分支重挂载操作后，初始化标记
     g_mutex_lock(&buff_lock);
     b_haveBuffer = FALSE;

     // 注册一次性缓冲区探针
     gst_pad_add_probe (srcpad,
                        GST_PAD_PROBE_TYPE_BUFFER,
                        (GstPadProbeCallback)have_buff,
                        NULL,
                        NULL);
        
     // 阻塞等待信号，不会空转占CPU，也不会阻塞GStreamer流线程（前提是loop_run运行在独立工作线程）
     while (!b_haveBuffer) {
         g_cond_wait(&buff_cond, &buff_lock);
     }
     g_mutex_unlock(&buff_lock);

     // 走到这里说明已经检测到缓冲区流过，直接执行后续状态变更逻辑
     // 所有状态处理逻辑都集中在这里，不需要散落到探针回调中
  }
}

关键注意事项 #

• 不要在pad探针回调中执行耗时操作、调用会修改管道状态的GStreamer API（比如增删元素、切换元素状态、修改pad链接），探针运行在流线程中，持有管道流锁，执行这类操作极易触发死锁。
• 如果所有逻辑都必须跑在GLib主循环线程中，不能开独立工作线程，可以把等待逻辑换成g_idle_add注册的空闲任务轮询标记位，不要直接在主循环里写阻塞while——探针触发后更新标记，空闲任务检测到标记变更后再执行后续逻辑，这样不会阻塞主循环派发事件。
• 不要用忙等轮询（循环中调用g_usleep）的方式等待，这种方式不仅CPU占用高，只要等待线程和回调派发线程重合就必然死锁，条件变量的通知机制是这类场景的标准解法。
• 把后续逻辑全放到探针回调里的方案不推荐，除了逻辑分散不利于调试，还很容易因为上下文不匹配触发锁问题、线程安全问题。

内容的提问来源于stack exchange，提问作者user1538798