linux之kill(SIGSTOP) 是否在 kill() 返回时生效

假设我有一个父进程和一个子进程(以例如 fork() 或 clone() 启动)在 Linux 上运行。进一步假设存在一些父子都可以修改的共享内存。

在父进程的上下文中，我想停止子进程并知道它实际上已经停止，而且子进程所做的任何共享内存写入对父进程都是可见的(包括任何同步或缓存刷新这在多处理器系统中可能需要)。

This answer ，谈到使用 kill(SIGSTOP) 停止子进程，包含一个有趣的花絮:

When the first kill() call succeeds, you can safely assume that the child has stopped.

这句话真的是真的吗？如果是的话，谁能解释一下，或者给我指点一些更详细的文档(例如 Linux 联机帮助页)？否则，我是否可以使用另一种机制来确保子进程完全停止并且不会再对共享内存进行任何写入？

我在想象一些类似的东西:

1. parent 发送不同的信号(例如 SIGUSR1)， child 可以处理该信号
2. child 处理 SIGUSR1 并在信号处理程序中执行类似 pthread_cond_wait() 的操作以安全地“停止”(尽管从内核的角度来看仍在运行)——这在我的脑海中还没有完全充实，只是一个想法

如果这个问题已经有了既定的解决方案，我想避免重新发明轮子。注意需要抢先停止子进程；在这种情况下，向子进程添加某种主动轮询不是一种选择。

如果它只存在于 Linux 上，pthread_suspend() 将是完美的......

请您参考如下方法:

听起来您应该使用带有处理程序的自定义信号，而不是 sigstop。

很少有人完全不关心 child 的状态，例如它可以从单个非原子 64 位写入中存储 32 位，或者在逻辑上夹在两个相关写入之间。

即使您是，POSIX 也允许操作系统不让共享写入对其他进程立即可见，因此子进程应该有机会调用 msync 以实现可移植性，以确保写入完全同步.