libwebsockets 多线程环境下 pollfd 操作线程安全问题分析

背景介绍

libwebsockets 是一个轻量级的 C 语言 WebSocket 库，广泛应用于高性能网络通信场景。在实际生产环境中，开发者经常需要将其作为高并发客户端使用，这就涉及到多线程环境下的线程安全问题。

问题现象

在 libwebsockets 4.3.3 版本中，当多个线程同时对不同的 WebSocket 连接调用 lws_callback_on_writable 函数时，经过长时间的性能测试后，程序会在 _lws_change_pollfd 函数中的断言处崩溃：

assert(wsi->position_in_fds_table < (int)pt->fds_count);

问题根源分析

1. 文件描述符表操作机制

libwebsockets 使用一个文件描述符表（fds 数组）来管理所有连接。当删除一个连接时，会调用 __remove_wsi_socket_from_fds 函数，该函数会将待删除的元素与数组最后一个元素交换位置，然后删除最后一个元素。

2. 多线程竞争条件

问题发生在以下场景：

1. 线程 A 正在为最新建立的连接调用 lws_callback_on_writable
2. 同时线程 B 正在销毁另一个连接

由于 fds 数组的交换操作不是原子性的，且 _lws_change_pollfd 函数中的断言检查没有适当的锁保护，导致在检查 position_in_fds_table 时可能遇到已经被交换或删除的元素，从而触发断言失败。

解决方案

1. 锁保护机制优化

通过分析代码，我们发现虽然 __remove_wsi_socket_from_fds 函数中已经有锁保护，但 _lws_change_pollfd 函数中的断言检查缺乏相应的锁保护。正确的做法是在访问共享数据结构前获取锁：

lws_pt_lock(pt, __func__);
assert(wsi->position_in_fds_table < (int)pt->fds_count);
/* 其他操作 */
lws_pt_unlock(pt);

2. 线程安全函数选择

虽然 libwebsockets 提供了线程安全的 lws_cancel_service_pt 函数，但直接使用 lws_callback_on_writable 在性能上更有优势。通过适当的锁保护，可以安全地使用后者。

性能考量

在优化后的代码中，我们需要注意：

1. 锁的粒度要尽可能小，只在必要时持有锁
2. 避免在锁保护区域内进行耗时操作
3. 保持锁获取和释放的对称性

经过测试，优化后的代码在 500,000 次调用（平均每秒 10 次，每次调用持续时间约 110 秒）的性能测试中表现稳定。

最佳实践建议

1. 在多线程环境中使用 libwebsockets 时，确保正确配置 LWS_MAX_SMP 参数
2. 对于高并发场景，考虑使用每个连接独立线程的架构
3. 定期检查 libwebsockets 的更新，获取最新的线程安全修复
4. 在性能关键路径上，优先使用直接操作而非间接通知机制

总结

libwebsockets 作为高性能 WebSocket 库，在多线程环境下需要特别注意共享数据结构的线程安全问题。通过对 _lws_change_pollfd 函数的锁保护优化，可以有效解决文件描述符表操作的竞争条件问题，同时保持良好的性能表现。开发者在使用时应当理解底层机制，合理设计线程模型，确保系统的稳定性和高性能。