1024 bites interleaving frequency???

[Giulio]

I made for experiment this simple program:

#include <stdlib.h>

int main (){
int i;
if (fork() != 0){
for (i = 0; i < 100000; i++) printf("|");
} else {
for (i = 0; i < 100000; i++) printf("-");
}
exit (0);
}

I tried to count how many '|' and how many '-' in my screen.
they where almost always blocks of 1024 '|' and 1024 '-'
sometimes longer blocks o shorter ones.. but most frequently blocks of
1024 chars...

do someone has an explanation for this fact??

Giulio

 

[Dave Vandervies]

I made for experiment this simple program:

if (fork() != 0){

do someone has an explanation for this fact??

fork() is not defined by the C language and therefore beyond the scope
of comp.lang.c .

The folks in comp.unix.programmer might be able to help you out.


dave

 

[Richard Tobin]

I tried to count how many '|' and how many '-' in my screen.
they where almost always blocks of 1024 '|' and 1024 '-'
sometimes longer blocks o shorter ones.. but most frequently blocks of
1024 chars...

The standard i/o library buffers its output by default. It then uses
some operating-system function to write out the buffer, and this may
well be an atomic operation with respect to switching between
processes.

-- Richard

 

[Gordon Burditt]

int main (){
int i;
if (fork() != 0){
for (i = 0; i < 100000; i++) printf("|");
} else {
for (i = 0; i < 100000; i++) printf("-");
}
exit (0);
}

I tried to count how many '|' and how many '-' in my screen.
they where almost always blocks of 1024 '|' and 1024 '-'
sometimes longer blocks o shorter ones.. but most frequently blocks of
1024 chars...

do someone has an explanation for this fact??

stdio output is often buffered (and since you're not outputting any
newline characters, line buffering turns into block buffering). I
wonder what the block size of the buffering is used in your
implementation? 1024 seems a reasonable choice.

Gordon L. Burditt

 

[Tom St Denis]

I made for experiment this simple program:

#include <stdlib.h>

int main (){
int i;
if (fork() != 0){
for (i = 0; i < 100000; i++) printf("|");
} else {
for (i = 0; i < 100000; i++) printf("-");
}
exit (0);
}

I tried to count how many '|' and how many '-' in my screen.
they where almost always blocks of 1024 '|' and 1024 '-'
sometimes longer blocks o shorter ones.. but most frequently blocks of
1024 chars...

do someone has an explanation for this fact??

It's actually quite trivial once you realize how printf actually sends
data from your argument to the file handle.

[Hint: think of buffering, think fflush....]

Tom

 

[Dan Pop]

I made for experiment this simple program:

#include <stdlib.h>

int main (){
int i;
if (fork() != 0){
for (i = 0; i < 100000; i++) printf("|");
} else {
for (i = 0; i < 100000; i++) printf("-");
}
exit (0);
}

I tried to count how many '|' and how many '-' in my screen.
they where almost always blocks of 1024 '|' and 1024 '-'
sometimes longer blocks o shorter ones.. but most frequently blocks of
1024 chars...

do someone has an explanation for this fact??

Your code is broken, so there is little point in trying to explain its
behaviour. Try the following fixed version and play with the setvbuf
call (replace _IOFBF by _IONBF or comment out the setvbuf call) and see
if it makes any difference.

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

#define SIZE 100000
char buff[SIZE];

int main()
{
int i;

setvbuf(stdout, buff, _IOFBF, sizeof buff);

if (fork() != 0) {
for (i = 0; i < SIZE; i++) putchar('p');
wait(NULL);
printf("\nBUFSIZ = %d\n", BUFSIZ);
}
else for (i = 0; i < SIZE; i++) putchar('c');

return 0;
}

As such, my program is quite likely to generate two compact blocks of
output (one generated by the parent, the other by the child) and then
the final line printed by the parent. But even this is not guaranteed.

Using the default buffering or disabling the stdio buffering is likely
to change the output pattern.

BTW, the issue is semi-topical, because it involves the buffering
performed by the standard C library. The off topic parts are the ones
related to creating a second process and waiting for its termination,
but without them the topical part could not be explored.

Dan

 

[Jason Curl]

I made for experiment this simple program:

#include <stdlib.h>

int main (){
int i;
if (fork() != 0){
for (i = 0; i < 100000; i++) printf("|");
} else {
for (i = 0; i < 100000; i++) printf("-");
}
exit (0);
}

I tried to count how many '|' and how many '-' in my screen.
they where almost always blocks of 1024 '|' and 1024 '-'
sometimes longer blocks o shorter ones.. but most frequently blocks of
1024 chars...

do someone has an explanation for this fact??

Your code is broken, so there is little point in trying to explain its
behaviour. Try the following fixed version and play with the setvbuf
call (replace _IOFBF by _IONBF or comment out the setvbuf call) and see
if it makes any difference.

#include <stdio.h>
#include <unistd.h>
#include <sys/wait.h>

#define SIZE 100000
char buff[SIZE];

int main()
{
int i;

setvbuf(stdout, buff, _IOFBF, sizeof buff);

if (fork() != 0) {
for (i = 0; i < SIZE; i++) putchar('p');
wait(NULL);
printf("\nBUFSIZ = %d\n", BUFSIZ);
}
else for (i = 0; i < SIZE; i++) putchar('c');

return 0;
}

As such, my program is quite likely to generate two compact blocks of
output (one generated by the parent, the other by the child) and then
the final line printed by the parent. But even this is not guaranteed.

Using the default buffering or disabling the stdio buffering is likely
to change the output pattern.

BTW, the issue is semi-topical, because it involves the buffering
performed by the standard C library. The off topic parts are the ones
related to creating a second process and waiting for its termination,
but without them the topical part could not be explored.

Dan

Wouldn't the scheduler be more pertinent here than any type of
buffering, etc.?

 

[Richard Tobin]

Try the following fixed version and play with the setvbuf
call (replace _IOFBF by _IONBF or comment out the setvbuf call) and see
if it makes any difference.

[...]

Wouldn't the scheduler be more pertinent here than any type of
buffering, etc.?

Why not try changing the buffering as Dan suggests, and see for yourself?

-- Richard