C语言多线程：线程能否终止主线程？中央服务器收不到ping可否终止运行

1. 多线程执行是否会阻塞主线程 #

注：C语言标准本身不定义多线程模型，目前Linux环境下C语言的多线程开发均基于POSIX pthread接口实现。在该模型下：

• 主线程和子线程是独立的执行流，由操作系统内核统一调度，子线程的常规执行逻辑本身不会让主线程停止运行。
• 只有两种场景会出现主线程卡住的情况：
  • 你在主线程中主动调用了pthread_join等待指定子线程退出
  • 主线程和子线程争夺同一把互斥锁、信号量，且子线程长期持有锁不释放
• 你草拟的“启动接收ping的子线程后直接进入主业务循环”的写法，只要没有主动等待子线程、没有不合理的锁竞争，两个线程就可以并行运行，不会互相阻塞。

2. 网络断网场景的专用信号处理器是否存在 #

你的判断完全正确：

• 操作系统没有专门对应“网络断网”事件的信号。信号的触发场景是进程内部的运行异常、外部终端中断（比如SIGINT、SIGSEGV），网络状态变化属于内核网络栈的事件，不会主动向用户进程投递信号。
• 如果需要感知网络状态，要么自己做主动检测（就是你计划的双向ping机制），要么在Linux环境下通过netlink套接字订阅内核的网络状态变更事件，这不属于信号处理的范畴，无法通过配置信号处理器直接实现。

3. 连续2分钟未收到对端ping时终止Server A的逻辑可行性 #

这个需求完全可以实现，但你当前草拟的代码框架存在明显的结构问题，修正后即可落地：

现有代码框架的问题 #

• Server B的代码把发ping的逻辑写在主while(1)循环内部，相当于每跑一次主业务循环就新建一个发ping的线程，短时间内就会创建大量无效线程，耗尽系统资源。
• Server A的接收ping线程和主业务循环之间没有状态同步机制，无法把“超时未收到包”的状态传递到主逻辑中触发终止流程。

正确的实现思路 #

1. 定义共享状态
   在Server A的进程内定义两个全局变量，配合互斥锁做多线程保护：
   • last_recv_ping_time：记录最后一次收到Server B ping包的系统时间戳，初始值为程序启动时的当前时间
   • ping_mutex：保护上面时间戳的互斥锁，避免多线程访问出现数据竞争
2. 修正Server A的线程结构
   • 启动一个长期运行的接收ping专用线程，不要在主循环里反复新建线程：线程内创建UDP socket，设置1秒的读超时，循环监听来自Server B的ping包；每收到一次合法ping包，就拿锁把last_recv_ping_time更新为当前系统时间。
   • 超时判断可以二选一：
     • 简单方案：在接收线程内，每次收包超时的时候，拿锁计算当前时间 - last_recv_ping_time的差值，如果超过120秒（2分钟），直接调用exit()终止整个进程（同进程内所有线程会随进程退出被统一回收）
     • 优雅方案：把超时判断放到Server A的主while(1)循环中，每轮执行业务逻辑前先拿锁计算时间差，超时后主动清理已占用的资源、打日志，再正常退出主循环终止程序，避免出现资源泄漏
3. 修正Server B的线程结构
   • 单独启动一个长期运行的发ping专用线程，不要在主循环里反复新建线程：线程内每间隔固定时间（比如1秒），向Server A的业务端口发送一个带约定标识的UDP报文即可。不需要调用系统原生ICMP ping（需要root权限），直接基于业务端口的UDP报文做检测即可，降低部署权限要求。

内容的提问来源于stack exchange，提问作者Rakshan Premsagar Kapikad