«

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

In article <co3529$htq$>,
Giulio <> wrote:
>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

--
Dave Vandervies
80% of all questions that begin with the word 'why' can be answered
with the simple sentence 'people are stupid.'
--Shamelessly Stolen From Mike in uw.general

In article <co3529$htq$>,
Giulio <> wrote:

>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

>#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??

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

Giulio <> wrote in message news:<co3529$htq$>...
> 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

In <co3529$htq$> Giulio <> writes:

>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
--
Dan Pop
DESY Zeuthen, RZ group
Email:
Currently looking for a job in the European Union

Dan Pop wrote:
> In <co3529$htq$> Giulio <> writes:
>
>
>>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.?

In article <co5217$imi$>,
Jason Curl <> wrote:
>> 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