我有一个类似“调试器”的应用程序,名为hyper-ptrace.它启动与NPTL多线程的user_appl3.

hyper-ptrace的主循环是：

wait3(&status, FLAGS, &u);
// find a pid of child, which has a signal
switch (signal = WSTOPSIG(status))
{
  case SIGTRAP:
    do_some_analysis_of_the_child(pid, &status) // up to several ms
    break;
}
ptrace(PTRACE_CONT, pid); // discard signal, user_appl3 doesn't know anything 
                          //about this SIGTRAP

SIGTRAP由硬件针对每个线程以一定的周期性间隔为user_appl3生成,并将其传递给某些线程.间隔可以是100..1 ms或更短.
这是一种带有中断的每CPU时钟.每个线程仅在其CPU上运行(与亲和力绑定).

所以有一个问题1：

如果线程1获得了TRAP,并且调试器进入了do_some_analysis_of_the_child(因此调试器不对第二个线程执行wait3),再过一会儿,线程2也获得了TRAP,Linux内核将如何处理？

我认为：线程1将停止,因为它得到一个信号并且有一个正在等待的调试器.但是thread2继续运行(是吗？).当线程2收到信号时,将没有等待的调试器,因此TRAP可以传递给线程2本身,从而有效地杀死它.我对吗？

第二个问题是question2：

对于这种情况,我应该如何重写hyper-ptrace的主循环,以降低通过调试器将信号传递到用户线程的机会？
也不能生成陷阱的硬件,也不能更改用户应用程序.停止第二个线程也不是变体.

我需要分析两个线程.有些零件只有在线程停止时才能完成.

提前致谢！

解决方法:

不,信号不会传递到应用程序.当信号发生时,子应用程序将停止,并且下次调用wait()时,您的跟踪过程将得到通知.

您是对的-跟踪停止仅适用于主线程.

要获得所需的行为,请在跟踪线程停止后立即通过向进程PID发送SIGSTOP来挂起整个子进程(每个线程),并在完成后使用SIGCONT对其进行恢复：

wait3(&status, FLAGS, &u);

if (WIFSTOPPED(status))
    kill(pid, SIGSTOP);  /* Signal entire child process to stop */

switch (signal = WSTOPSIG(status))
{
  case SIGTRAP:
    do_some_analysis_of_the_child(pid, &status) // up to several ms
    break;
}

ptrace(PTRACE_CONT, pid, 0, 0); // discard signal, user_appl3 doesn't know anything about this SIGTRAP
kill(pid, SIGCONT);  /* Signal entire child process to resume */