printf is buffered, that means that may be printed later, when the buffer is flushed. And it is only occurred when it is full. Or explicitly flushed.

Consider writing an actual multi-threaded program. Look up pthread_create (), pthread_join (), pthread_mutex_lock (), pthread_mutex_unlock (), etc.

In a multithreaded program, all threads share the same address space. This makes it easy to assign work to threads and to keep the results in a desired order.
Ed

Sorry, this meme is obligatory:

https://www.reddit.com/r/aww/comment..._and_practice/

1 members found this post helpful.

I have written a lot of multithreaded programs. Multithreaded programming is not particularly hard as long as the locks are done properly. The reputation comes from locking problems being very hard to debug.
Ed

Haha, that's impressive. I'm just an undergraduate student who is worried about his assignments 😂. I will definitely consider your suggestions in the future. Thanks!

Not seen that one before. Love it.
Thanks for sharing.

Your basic confusion comes from "what is happening behind the scenes." As each of the independently-running "child processes" consume their STDINs and generate their STDOUTs and STDERRs, they of course do so independently. But what you might not initially realize is that there is another(!) process out there which is gathering those various STDOUT/STDERR streams together from the various children, and delivering them "to one place." Whether that place is a disk file or your terminal window.

Each of the individual "child" streams are of course independent, but the gathering ("parent ...") process is not. This process, which you do not control, is ultimately responsible for the final output that you see. This process has several independent input-streams (one for each child process ...) to read from simultaneously, and it reads from them in no predictable order.

That's exactly what I'm confused about. Whatever is going on behind the scenes, the difference between the disk file and my terminal window should only be in order, but not in content. (Again, output in a file has two more lines than one in terminal)

The main difference between a disk file and a terminal is the way they are buffered. But that still doesn't explain the question above.

I have that explained already.
the printf("init") will put the text into a buffer. The fork process(es) will duplicate the process (3 fork will make it 3 times) and the buffer is duplicated too.
The flush command will be automatically executed (when that buffer is full) - after that fork, so all the three children will flush their own instance of that buffer. You can simply check it by flushing it before fork.

1 members found this post helpful.

But it still can't explain how different buffer types affect the behavior. Your descreption should be a **Commonality**.

Btw, the Windows icon sucks. Transparent background could be better.

Especially whem i'm using "Dark Reader"
https://raw.githubusercontent.com/fr...1120000849.png

I skimmed the thread quicky, so this may have been mentioned already, but the difference is that for terminals the buffer is automatically flushed whenever you print a newline (by default). Whereas for files, it's every 4096(?) bytes or so.

https://manned.org/setvbuf.3

That is what I really hate, the "implied" "intelligence". But anyway, you are right, the c library (of printf) detects the type of the output and may act accordingly.

Sorry, this is my fault. #24 is the correct answer for me.

The key point is the inheritance feature of fork(), which includes buffers.
In the case of using block buffers, when fork() is called, there is some content that has not yet been flushed to its destination. Each child gets a copy to its own buffer (now there are N+1 buffers).
These copies are the extra lines in the output.
In the case of line-buffering, the buffer is refreshed for each line. So when fork() is called, the buffers are empty.

As a little experiment, you can remove the "\n" after "init". Then you can get the expected behavior.

1 members found this post helpful.

Yeah, fork() – in both Unix® and Linux® – is a lot more expansive than the users of many other systems expect it to be, if they're accustomed to a mere "CreateProcess()" system function!