Tại sao một chương trình với fork () đôi khi in đầu ra của nó nhiều lần?

Trong Chương trình 1 Hello worldđược in chỉ một lần, nhưng khi tôi gỡ bỏ \nvà chạy nó (Chương trình 2), đầu ra được in 8 lần. Ai đó có thể vui lòng giải thích cho tôi tầm quan trọng của \nở đây và nó ảnh hưởng đến như thế nào fork()?

Chương trình 1

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main()
{
    printf("hello world...\n");
    fork();
    fork();
    fork();
}

Đầu ra 1:

hello world... 

Chương trình 2

#include <sys/types.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>

int main()
{
    printf("hello world...");
    fork();
    fork();
    fork();
}

Đầu ra 2:

hello world... hello world...hello world...hello world...hello world...hello world...hello world...hello world...

Khi xuất ra đầu ra tiêu chuẩn bằng printf()chức năng của thư viện C , đầu ra thường được đệm. Bộ đệm không được xóa cho đến khi bạn xuất một dòng mới, gọi fflush(stdout)hoặc thoát khỏi chương trình (không thông qua gọi _exit()). Luồng đầu ra tiêu chuẩn theo mặc định được đệm theo cách này khi được kết nối với TTY.

Khi bạn rẽ nhánh tiến trình trong "Chương trình 2", các tiến trình con sẽ kế thừa mọi phần của tiến trình cha, bao gồm cả bộ đệm đầu ra không được quét. Điều này sao chép một cách hiệu quả bộ đệm không bị xóa cho mỗi tiến trình con.

Khi quá trình kết thúc, bộ đệm được tuôn ra. Bạn bắt đầu tổng cộng tám quy trình (bao gồm cả quy trình ban đầu) và bộ đệm không được quét sẽ bị xóa khi kết thúc mỗi quy trình riêng lẻ.

Đó là tám vì mỗi lần fork()bạn nhận được gấp đôi số tiến trình bạn đã có trước fork()(vì chúng là vô điều kiện) và bạn có ba trong số các quy trình này (2 ³ = 8).

Nó không ảnh hưởng đến ngã ba theo bất kỳ cách nào.

Trong trường hợp đầu tiên, bạn kết thúc với 8 quy trình không có gì để ghi, vì bộ đệm đầu ra đã bị xóa (do \n).

Trong trường hợp thứ hai, bạn vẫn có 8 tiến trình, mỗi tiến trình có một bộ đệm chứa "Hello world ..." và bộ đệm được ghi ở cuối quá trình.

@Kusalananda giải thích tại sao đầu ra được lặp lại . Nếu bạn tò mò tại sao đầu ra được lặp lại 8 lần và không chỉ 4 lần (chương trình cơ sở + 3 dĩa):

int main()
{
    printf("hello world...");
    fork(); // here it creates a copy of itself --> 2 instances
    fork(); // each of the 2 instances creates another copy of itself --> 4 instances
    fork(); // each of the 4 instances creates another copy of itself --> 8 instances
}

Bối cảnh quan trọng ở đây là stdoutbắt buộc phải được đệm theo tiêu chuẩn như thiết lập mặc định.

Điều này gây ra một \nđể tuôn ra đầu ra.

Vì ví dụ thứ hai không chứa dòng mới, đầu ra không bị xóa và khi fork()sao chép toàn bộ quá trình, nó cũng sao chép trạng thái của stdoutbộ đệm.

Bây giờ, các fork()cuộc gọi này trong ví dụ của bạn tạo tổng cộng 8 quy trình - tất cả chúng đều có một bản sao trạng thái của stdoutbộ đệm.

Theo định nghĩa, tất cả các quy trình này gọi exit()khi trở về main()và exit()các cuộc gọi fflush()theo sau fclose()trên tất cả các luồng stdio hoạt động . Điều này bao gồm stdoutvà kết quả là, bạn thấy cùng một nội dung tám lần.

Đó là một cách thực hành tốt để gọi fflush()tất cả các luồng có đầu ra đang chờ xử lý trước khi gọi fork()hoặc để cho đứa trẻ rẽ nhánh gọi một cách rõ ràng _exit()rằng chỉ thoát khỏi quy trình mà không xóa các luồng stdio.

Lưu ý rằng việc gọi exec()không xóa bộ đệm stdio, vì vậy không cần quan tâm đến bộ đệm stdio nếu bạn (sau khi gọi fork()) gọi exec()và (nếu không) gọi _exit().

BTW: Để hiểu rằng bộ đệm sai có thể gây ra, đây là một lỗi cũ trong Linux đã được sửa gần đây:

Tiêu chuẩn này đòi hỏi stderrphải được giải mã theo mặc định, nhưng Linux đã bỏ qua điều này và tạo ra stderrdòng đệm và (thậm chí tệ hơn) được đệm hoàn toàn trong trường hợp stderr được chuyển hướng qua một đường ống. Vì vậy, các chương trình được viết cho UNIX đã thực hiện công cụ đầu ra mà không có dòng mới quá muộn trên Linux.

Xem bình luận dưới đây, nó dường như được sửa chữa ngay bây giờ.

Đây là những gì tôi làm để giải quyết vấn đề Linux này:

    /* 
     * Linux comes with a broken libc that makes "stderr" buffered even 
     * though POSIX requires "stderr" to be never "fully buffered". 
     * As a result, we would get garbled output once our fork()d child 
     * calls exit(). We work around the Linux bug by calling fflush() 
     * before fork()ing. 
     */ 
    fflush(stderr); 

Mã này không gây hại cho các nền tảng khác vì việc gọi fflush()một luồng vừa bị xóa là không có.