私は主にLinuxをターゲットとするGUI指向のデバッガーを書いていますが、将来的には他のOSへの移植を計画しています。GUIは常にインタラクティブである必要があるため、さまざまな処理を行うスレッドがいくつかあります。
主に、waitpidが戻るのを待ってループし、受信したイベントを他のスレッドに配信する「デバッグイベント」スレッドがあります。これを行うのは、waitpidにタイムアウトがないため、他のイベントループと統合して応答性を維持することが非常に困難になるためです（waitpidは無期限にハングする可能性があります）。
この戦略は、これまでのLinuxビルドでうまく機能しました。最近、デバッガースレッドを認識させようとしています（デバッガー自体ではなく、デバッグされたアプリケーションのスレッドのように）。
そこで、クローンイベントを追跡するようにptraceオプションを設定し、上位16ビットがに設定されているステータスを探しますPTRACE_EVENT_CLONE。次にPTRACE_GETEVENTMSG、新しいスレッドのTIDを取得するために使用します。これはすべて、私の小さなテストハーネスアプリケーションでうまく機能します。しかし、何らかの理由で、そのコードを実際のデバッガーに配置すると失敗します。（「そのようなプロセスはありません」というエラーコードが表示されます）
私が思いついたのは、Windowsには、アプリケーションに接続されたスレッドだけがデバッグイベントをリッスンできるというルールがあるということです。Linuxのptraceにも同様の制限がありますか？もしそうなら、なぜ私のコードは他のデバッグイベントで機能するのですか？
編集：
少なくともwaitpidは別のスレッドからの待機をサポートしているようです。manページには次のように書かれています。
Linux 2.4より前は、スレッドはプロセスの特殊なケースでした。その結果、別のスレッドが同じスレッドグループに属している場合でも、あるスレッドは別のスレッドの子を待つことができませんでした。ただし、POSIXはそのような機能を規定しており、Linux 2.4以降、スレッドは同じスレッドグループ内の他のスレッドの子を待機できます。デフォルトでは待機します。
したがって、これはせいぜいptraceの制限です。