Предварительный способ получить pid из tid

Этот вопрос касается не идентификаторов потоков, а значений, обычно получаемых gettid или ptrace.

Предоставляет ли ядро ​​linux какой-либо механизм для получения идентификатора группы потоков (обычно полученного getpid) из заданного tid относительно эффективным способом? Что-то, что не требует io или синтаксического анализа?

Единственный метод, кажется, open/proc/TID/status, read файл в буфер, построчное сканирование для Tgid, а затем синтаксический анализ строки как целое число без знака.

Я надеюсь, что есть системный вызов, который я пропустил, который возвращает tgid / pid с учетом pid, даже если идентификатор возвращается косвенно в некоторой структуре данных.

Возможный дубликат stackoverflow.com/questions/26508413/… Также имейте в виду, что TID могут быть переработаны, поэтому даже если вы каким-то образом получите идентификатор группы потоков, он может стать недействительным в следующий момент (т.е. поток завершается, другой процесс порождает новый поток, он получает тот же TID). Правильный способ идентифицировать поток - использовать пару (PID, TID), а не только TID. Конечно, PID тоже можно переработать ...

n. 1.8e9-where's-my-share m. 10.09.2018 09:55

К сожалению, решение, предложенное в stackoverflow.com/questions/26508413/…, требует нескольких системных вызовов и синтаксического анализа. Кроме того, в моем конкретном случае есть надлежащие проверки того, что tid является тем, чем он должен быть. Я надеюсь на что-то вроде getpgid, но вернет pid, а не идентификатор группы.

Tenders McChiken 10.09.2018 10:03

Дело в том, что такого системного вызова нет. Вы так или иначе читаете /proc.

n. 1.8e9-where's-my-share m. 10.09.2018 10:11

Жаль, пожалуйста, оставьте свой комментарий в качестве ответа, чтобы я мог его принять. Спасибо.

Tenders McChiken 10.09.2018 10:20
1
4
622
2
Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Ответ принят как подходящий

Похоже, такого системного вызова нет. Информацию можно получить только из /proc, и ваше текущее решение выглядит наиболее эффективным способом сделать это.

просто добавляя к уже имеющимся ответам. Действительно, в Linux нет лучшей альтернативы. Я сам искал что-то получше, и я нашел этот проект, который пытался предложить что-то более удобное для использования программным способом:

https://criu.org/Task-diag

Однако ничего из этого не происходит, вероятно, потому, что в настоящий момент слишком мало людей действительно заботятся о проблеме. В основном это касается высокопроизводительных приложений трассировки на уровне ОС и приложений реального времени, которые в Linux только зарождаются.

Интересный факт, в других подобных ОС этой проблемы нет (OpenBSD, QNX, ...)

Другие вопросы по теме