OS: Linux, Language: pure C
I'm moving forward in learning C programming in general, and C programming under UNIX in a special case.
I detected a strange (for me) behaviour of the printf()
function after using a fork()
call.
Code
#include <stdio.h>
#include <system.h>
int main()
{
int pid;
printf( "Hello, my pid is %d", getpid() );
pid = fork();
if( pid == 0 )
{
printf( "\nI was forked! :D" );
sleep( 3 );
}
else
{
waitpid( pid, NULL, 0 );
printf( "\n%d was forked!", pid );
}
return 0;
}
Output
Hello, my pid is 1111
I was forked! :DHello, my pid is 1111
2222 was forked!
Why did the second "Hello" string occur in the child's output?
Yes, it is exactly what the parent printed when it started, with the parent's pid
.
But! If we place a \n
character at the end of each string we get the expected output:
#include <stdio.h>
#include <system.h>
int main()
{
int pid;
printf( "Hello, my pid is %d\n", getpid() ); // SIC!!
pid = fork();
if( pid == 0 )
{
printf( "I was forked! :D" ); // removed the '\n', no matter
sleep( 3 );
}
else
{
waitpid( pid, NULL, 0 );
printf( "\n%d was forked!", pid );
}
return 0;
}
Output:
Hello, my pid is 1111
I was forked! :D
2222 was forked!
Why does it happen? Is it correct behaviour, or is it a bug?
Best Answer
I note that
<system.h>
is a non-standard header; I replaced it with<unistd.h>
and the code compiled cleanly.When the output of your program is going to a terminal (screen), it is line buffered. When the output of your program goes to a pipe, it is fully buffered. You can control the buffering mode by the Standard C function
setvbuf()
and the_IOFBF
(full buffering),_IOLBF
(line buffering) and_IONBF
(no buffering) modes.You could demonstrate this in your revised program by piping the output of your program to, say,
cat
. Even with the newlines at the end of theprintf()
strings, you would see the double information. If you send it direct to the terminal, then you will see just the one lot of information.The moral of the story is to be careful to call
fflush(0);
to empty all I/O buffers before forking.Line-by-line analysis, as requested (braces etc removed - and leading spaces removed by markup editor):
printf( "Hello, my pid is %d", getpid() );
pid = fork();
if( pid == 0 )
printf( "\nI was forked! :D" );
sleep( 3 );
else
waitpid( pid, NULL, 0 );
printf( "\n%d was forked!", pid );
The analysis:
pid == 0
and executes lines 4 and 5; the parent has a non-zero value forpid
(one of the few differences between the two processes - return values fromgetpid()
andgetppid()
are two more).The parent now exits normally through the return at the end of main, and the residual data is flushed; since there still isn't a newline at the end, the cursor position is after the exclamation mark, and the shell prompt appears on the same line.
What I see is:
The PID numbers are different - but the overall appearance is clear. Adding newlines to the end of the
printf()
statements (which becomes standard practice very quickly) alters the output a lot:I now get:
Notice that when the output goes to the terminal, it is line-buffered, so the 'Hello' line appears before the
fork()
and there was just the one copy. When the output is piped tocat
, it is fully-buffered, so nothing appears before thefork()
and both processes have the 'Hello' line in the buffer to be flushed.