libdatachannel项目中MbedTLS导致WebSocketServer双锁问题的分析与解决

问题背景

在libdatachannel项目中，当启用MbedTLS加密支持时，使用rtc::WebSocketServer类处理WebSocket连接会出现双锁异常。这个问题在v0.42.0版本中被发现，具体表现为当服务器处理Ping-Pong心跳消息时，系统会抛出"device or resource busy"异常。

问题现象

当WebSocket服务器和客户端都使用MbedTLS加密连接时，服务器在运行几秒钟后会意外断开连接。通过调试发现，问题发生在处理零长度Ping消息的过程中，系统尝试对同一个互斥锁进行二次加锁。

技术分析

锁竞争过程

1. 第一次加锁：发生在接收Ping消息的过程中，TlsTransport::doRecv()方法首先获取mSslMutex锁
2. 第二次加锁：在消息处理回调链中，最终又回到了TlsTransport::send()方法，该方法再次尝试获取同一个mSslMutex锁

根本原因

MbedTLS库本身不是线程安全的，对同一上下文的所有操作必须在同一线程中完成。当WebSocket服务器处理Ping消息时，接收回调触发了发送操作，导致对同一个SSL上下文进行嵌套操作，从而引发了双锁问题。

解决方案

项目维护者提出了两种可能的解决方案：

1. 递归锁方案：将现有的普通互斥锁改为递归锁，允许同一线程多次加锁
2. 异步发送方案：将Ping消息的发送操作放到线程池中异步执行，避免在接收回调中直接发送

最终项目采用了第一种方案，即使用递归锁来解决这个问题。这种方案实现简单，且能保证MbedTLS操作的线程安全性。

技术启示

1. 加密库线程安全：在使用加密库时需要特别注意其线程安全特性，MbedTLS要求同一上下文的所有操作必须串行化
2. 回调设计：在设计网络库的回调机制时，需要考虑回调中可能触发的其他操作，避免形成操作环
3. 锁的选择：在特定场景下，递归锁可能是解决嵌套操作的有效方案，但需要权衡性能影响

这个问题展示了在网络编程中，特别是结合加密功能时，线程安全和锁管理的重要性。开发者在设计类似系统时，应当充分考虑操作流程中可能出现的嵌套调用情况。