Проблема в том, что есть несколько процессов, одновременно записывающих в один и тот же файл (вашу консоль) без какого-либо контроля параллелизма или какой-либо блокировки. Это, и что эти странные существа, в лучшем случае, делают странные вещи, происходящие. Кроме того, помните, что printf
буферизовано.
Ваш вывод должен читаться следующим образом:
Child pid: 1450 <- Child #1
Parent id: 1445 <- Parent #1.1
Its child id: 1450 <- Parent #1.2
Child pid: 1455[Its child id: 1450] <- Child #2 with garbage at the end
Parent id: 1445 <- Parent #2.1
Its child id: 1455 <- Parent #2.2
Child pid: 1460[Its child id: 1455] <- Child #3 with garbage at the end
Parent id: 1445 <- Parent #3.2
Its child id: 1460 <- Parent #3.2
Вы можете попробовать перенаправить вывод в файл и посмотреть, не имеет ли значение tty.
В любом случае, чтобы сделать это правильно, вам следует использовать любой механизм, который гарантирует многопроцессорную корректность.
UPDATE
Да, теперь я вижу это. У вас есть '\ n' в начале ваших строк печати, а не в конце, как обычно. Stdout обычно буферизуется строкой, это означает, что буфер сбрасывается на устройство, когда он видит '\ n'. И поскольку они у вас есть в начале, в буфере всегда есть одна строка, ожидающая вывода.
Теперь, когда вы fork
обрабатываете свой процесс, выходной буфер дублируется, и последняя строка из родительского элемента печатается дочерним элементом (почему он печатается после , а не до, все еще остается загадкой). мне).
В любом случае, добавленный вами новый printf
имеет в конце '\ n', поэтому он очищает буфер, fork
находит его пустым и все идет хорошо. С таким же успехом можно позвонить fflush(stdout)
, но это громоздко.
Мораль истории такова: «Когда вы printf
для целей отладки всегда ставьте \n
в конце каждой строки, или вы можете получить частичное, смешанное содержимое.