我正在尝试理解使用多线程的分叉。那个么在下面的场景中会发生什么呢？
- 应用程序线程生成了一个线程轮询线程
- 应用程序线程运行分叉
- atpthread_fork处理程序的pre_fork使用std:：condition_variable停止轮询线程。它还等待不同的条件变量来恢复轮询
- atpthread_fork处理程序的post_fork in child为等待的轮询线程执行cv.notify_one并停止轮询线程
- atpthread_fork处理程序的post_fork in parent为等待的轮询线程执行cv.notify_one并恢复轮询线程
但实际情况是，child中的post_fork进入了一个无限循环，它一直在等待。这似乎也根本没有通知轮询线程cv。
为什么会发生这种情况？
我正在尝试理解使用多线程的分叉。
将分叉与多线程相结合的首要问题是不要这样做。除了少数特殊情况外，这种组合还有很大的问题。
那么下面的场景会发生什么呢？
- 应用程序线程生成了一个线程轮询线程
- 应用程序线程运行分叉
- atpthread_fork处理程序的pre_fork使用std:：condition_variable停止轮询线程。它也在不同的条件下等待变量以恢复轮询
这毫无意义。条件变量没有能力抢先停止任何线程。如果轮询线程最终阻止了CV，那么一个不同的CV在重新启动它时会扮演什么角色？
- atpthread_fork处理程序的post_fork in child为等待的轮询线程执行cv.notify_one并停止轮询线程
我想你的意思是说，通过pthread_atfork注册的post_fork处理程序在子线程中执行cv.notify_one，以恢复轮询线程。
无论如何，孩子都不可能对轮询线程做任何事情，因为它没有轮询线程。子进程只有一个线程——一个调用fork()的线程的副本。这就是为什么分叉和多线程不能混合的主要原因之一。
- atpthread_fork处理程序的post_fork在parent中为等待的轮询线程执行cv.notify_one并恢复轮询线程
考虑到你将其归因于简历的整体可疑行为，这似乎是有问题的，但这个概念本身并没有什么问题。
但实际情况是，child中的post_fork进入一个无限循环，其中它一直在等待。
此处缺少某些内容。你在做定时等待吗？它的等待失败了吗？这些是我唯一能想到的孩子既可以循环又可以等待的方式。最初，子进程中没有其他线程来唤醒由fork产生的单个线程，因此线程无法从对任何CV的等待中成功返回，除非不稳定。没有人发出信号。
这似乎也没有通知投票线程cv。
你是指孩子身上不存在的那个吗？或者父母中可能没有在等待你认为正在等待的简历的人？
以上大部分内容都没有实际意义。绝对没有理由认为您的程序正在执行一个特殊的异常，所以请参阅#1：不要将分叉与多线程结合起来。选择一个。