LINUX.ORG.RU

Разница между man 2 и man 3

 , , , ,


0

1

Столкнулся с очень неприятной проблемой.

Если одна и та-же функция описана как секции мануала 2 - Unix and C system calls так и в 3 - C library routines for C programs.

Но описание поведеня у функции разное. Как определить поведение у себя в программе? Или как явно сообщить что я хочу использовать именно systemCall или C library function? Ведь и там и так одна и таже сигнатура функции и одни и теже инклуды.

Конкретно я столкнулся в функцией waitpid.

В man 2 говорится так :

The waitpid() system call suspends execution of the calling process until a child specified by pid argument has changed state.

В man 3 говорится так :

The wait() function shall suspend execution of the calling thread until status information for one of the terminated child processes of the calling process is available ... The waitpid() function shall be equivalent to wait() if the pid argument is (pid_t)-1 and the options argument is 0.

Я сначала был уверен в том, что на waitpid уснут потоки моего процесса (согластно man2), а по факту усыпал только один ( согластно man3)

если пользуешься функциями из libc - читай man 3, если дергаешь сисколы напрямую (через функцию syscall() или из asm) - читай man 2

путаница может возникнуть из-за того, что многие функции из libc называются 1 в 1 как системные вызовы, но по факту являются лишь обертками над ними, часто с отличающимся поведением

anonymous ()
Ответ на: комментарий от anonymous

а еще в man'ах -каша, сама функция (libc'шная) syscall() описана в man 2, хотя является всего лишь сишным костылем для вызова сисколлов

anonymous ()

Я сначала был уверен в том, что на waitpid уснут потоки моего процесса (согластно man2)

попробуйте процитировать ту часть man2 с которой взялась ваша уверенность. У вас какие-то воспоминания про виндовс видимо, где процесс отдельно, нить отдельно.. И в man2 и в man3 всё корректно

MKuznetsov ★★★★★ ()

Я никогда не сталкивался с тем, чтобы что-либо усыпляло все потоки процесса. Мне кажется, таких функций нет. Поток или работает или спит потому, что он сам вызвал какую-то функцию. Думаю в (2) ман просто старый, можешь найти ответственных и засандалить им пулл-реквест на исправление, если не лень. Раньше в линуксе не было потоков, только процессы, видимо с тех пор никто эти маны не правил.

Legioner ★★★★★ ()

man 2 — это описания применительно к Линуксу и только к нему. man 3 — это с точки зрения libc. man 3p — цитаты из POSIX.

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от anonymous

А как указать явно что я хочу использовать функцию из libc или системный вызов?

letitbe ()
Ответ на: комментарий от intelfx

man 2 — это описания применительно к Линуксу и только к нему.

Вот это действительно полезная информация, спасибо. Получается, что если я запускаю свою прогамму на Linux, то буду ождать поведение из man 2? Или как-то по другому определяеся, какое именно поведение функции я могу ожидать,

letitbe ()
Ответ на: комментарий от MKuznetsov

Вот эта часть :

The waitpid() system call suspends execution of the calling process

Если в мане пишется, что поток будем suspended, то я воспринимаю это так что все потоки этого процесса будут suspended.

letitbe ()
Ответ на: комментарий от letitbe

Если в мане пишется, что поток будем suspended, то я воспринимаю это так что все потоки этого процесса будут suspended.

Ну чисто логически, как бы тогда waitpid() дожидался завершения уснувшего потока?

madcore ★★★★★ ()
Ответ на: комментарий от letitbe

Да. Я бы сказал по-другому: если ты собираешься запускать свою программу только под Linux, то ты имеешь право «завязываться» на особенности поведения и дополнительные нестандартные фичи, описанные в man 2. А если ты хочешь сделать свою программу портируемой на другие ОС с другими ядрами и другими реализациями стандартных библиотек, то тебе нельзя так делать — ты имеешь право полагаться только на то, что документировано в man 3p.

intelfx ★★★★★ ()
Ответ на: комментарий от letitbe

посмотрите как порождаются потоки и всё встанет на свои места.

хинт: через vfork можно порождать близкий аналог pthread. «process» в данном контексте всё равно что thread.

MKuznetsov ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.