Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #57832 > unrolled thread

forking madness

Back to article view | Back to comp.lang.c

Contents

  forking madness Ruben Safir <mrbrklyn@panix.com> - 2015-03-02 23:41 +0000
    Re: forking madness Keith Thompson <kst-u@mib.org> - 2015-03-02 16:05 -0800
      Re: forking madness fir <profesor.fir@gmail.com> - 2015-03-03 01:20 -0800
        Re: forking madness Noob <root@127.0.0.1> - 2015-03-03 15:50 +0100
          Re: forking madness fir <profesor.fir@gmail.com> - 2015-03-03 07:57 -0800
        Re: forking madness Nobody <nobody@nowhere.invalid> - 2015-03-07 07:07 +0000
          Re: forking madness fir <profesor.fir@gmail.com> - 2015-03-07 05:05 -0800
    Re: forking madness Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-03-02 19:25 -0500
      Re: forking madness Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-03-02 19:32 -0500
      Re: forking madness ruben <nowhere@nowhere.nor> - 2015-03-03 14:56 +0000
        Re: forking madness Keith Thompson <kst-u@mib.org> - 2015-03-03 07:54 -0800
      Re: forking madness asetofsymbols@gmail.com - 2015-03-05 00:03 -0800
        Re: forking madness asetofsymbols@gmail.com - 2015-03-05 00:21 -0800
          Re: forking madness asetofsymbols@gmail.com - 2015-03-05 00:44 -0800
    Re: forking madness Lőrinczy Zsigmond <nospam@for.me> - 2015-03-03 17:45 +0100
      Re: forking madness Keith Thompson <kst-u@mib.org> - 2015-03-03 09:44 -0800
        Re: forking madness Lőrinczy Zsigmond <nospam@for.me> - 2015-03-03 19:06 +0100
          Re: forking madness James Kuyper <jameskuyper@verizon.net> - 2015-03-03 13:57 -0500
            Re: forking madness Lőrinczy Zsigmond <nospam@for.me> - 2015-03-04 06:53 +0100
              Re: forking madness Chad <cdalten@gmail.com> - 2015-03-05 14:09 -0800

#57832 — forking madness

Anyone know why this might not fuction as I thought it might.  It seems
to start at the beginning of main when a process is forked

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


int main( int argc, char * argv[]){
        pid_t pid;
        pid_t pid_ret;
        int i = 0;
        printf("\n___Before the While Loop where Loop is ==> %d__", i);

        while( i++ < 100){
                puts("\nBefore the Fork in the Loop:");
                printf( "Loop ==> %d \n", i);
                pid = fork();
                printf("\nFork: This should print twice for every loop:
%d", i);

        if(pid < 0){
                puts( "fork failed\n" );
                return 1;
        }
        if(pid == 0) {
                puts("\n\nChildren of the world unite");
                printf("Am Yisrael Chai! pid =>%d \n", pid);
                printf( "Loop in Child ==> %d \n", i);
                puts("BYE!!");
                exit( EXIT_SUCCESS );
        }
        if (pid > 0 ){
                printf("\nIn the  Parent => I'm waiting %d\n", pid );
                printf( "Loop in Parent ==> %d \n", i);
                pid_ret = wait(NULL);
                puts("Done Waiting for Child");
                printf("\nProcess that returned was ==> %d", pid_ret );
                printf("\n*******************************\n" );
        }
        }
        return 0;
}

~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

___Before the While Loop where Loop is ==> 0__
Before the Fork in the Loop:
Loop ==> 1

Fork: This should print twice for every loop: 1

Children of the world unite
Am Yisrael Chai! pid =>0
Loop in Child ==> 1
BYE!!

___Before the While Loop where Loop is ==> 0__
Before the Fork in the Loop:
Loop ==> 1

Fork: This should print twice for every loop: 1
In the  Parent => I'm waiting 29294
Loop in Parent ==> 1
Done Waiting for Child

Process that returned was ==> 29294
*******************************

Before the Fork in the Loop:
Loop ==> 2

Fork: This should print twice for every loop: 2

Children of the world unite
Am Yisrael Chai! pid =>0
Loop in Child ==> 2
BYE!!

___Before the While Loop where Loop is ==> 0__
Before the Fork in the Loop:
Loop ==> 1

Fork: This should print twice for every loop: 1
In the  Parent => I'm waiting 29294
Loop in Parent ==> 1
Done Waiting for Child

[toc] | [next] | [standalone]

#57833

Ruben Safir <mrbrklyn@panix.com> writes:
> Anyone know why this might not fuction as I thought it might.  It seems
> to start at the beginning of main when a process is forked
>
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <stdlib.h>
[snip]

fork() is not a standard C function.  It's defined by POSIX, a secondary
standard.  Because of this, you're likely to get better answers if you
post to comp.unix.programmer.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#57838

W dniu wtorek, 3 marca 2015 01:06:05 UTC+1 użytkownik Keith Thompson napisał:
> Ruben Safir <mrbrklyn@panix.com> writes:
> > Anyone know why this might not fuction as I thought it might.  It seems
> > to start at the beginning of main when a process is forked
> >
> > #include <sys/types.h>
> > #include <sys/wait.h>
> > #include <stdio.h>
> > #include <unistd.h>
> > #include <stdlib.h>
> [snip]
> 
> fork() is not a standard C function.  It's defined by POSIX, a secondary
> standard.  Because of this, you're likely to get better answers if you
> post to comp.unix.programmer.
> 

I disagree, some tend to like treat c in extremally narrow way, For me even the topics concerning something like game dev
or graphics topics but in c implementation are on topic here, same as topics of c libraries, details of c compilers etc

[toc] | [prev] | [next] | [standalone]

#57840

fir wrote:

> Keith Thompson wrote:
>  
>> fork() is not a standard C function.  It's defined by POSIX, a secondary
>> standard.  Because of this, you're likely to get better answers if you
>> post to comp.unix.programmer.
>
> I disagree, some tend to like treat c in extremely narrow way, For
> me even the topics concerning something like game dev or graphics
> topics but in c implementation are on topic here, same as topics of c
> libraries, details of c compilers etc

Yeah!! Fuck this hierarchical organization nonsense!
Whoever thought there would be any point to it?!

Everyone should (no, wait.) Everyone MUST answer any question, however remotely
related to the C language; debuggers, assembly code (what assembly language,
you ask, well, all of them, of course!), linters, parsers, lexers, anything
inspired from C's syntax, etc.

Let's get the ball rolling! How do I set up my editor (Notepad) to highlight
according to Visual C95 syntax?

FFS. I think you're worse than aminer.

[toc] | [prev] | [next] | [standalone]

#57849

W dniu wtorek, 3 marca 2015 15:50:41 UTC+1 użytkownik Noob napisał:
> fir wrote:
> 
> > Keith Thompson wrote:
> >  
> >> fork() is not a standard C function.  It's defined by POSIX, a secondary
> >> standard.  Because of this, you're likely to get better answers if you
> >> post to comp.unix.programmer.
> >
> > I disagree, some tend to like treat c in extremely narrow way, For
> > me even the topics concerning something like game dev or graphics
> > topics but in c implementation are on topic here, same as topics of c
> > libraries, details of c compilers etc
> 
> Yeah!! Fuck this hierarchical organization nonsense!
> Whoever thought there would be any point to it?!
> 
> Everyone should (no, wait.) Everyone MUST answer any question, however remotely
> related to the C language; debuggers, assembly code (what assembly language,
> you ask, well, all of them, of course!), linters, parsers, lexers, anything
> inspired from C's syntax, etc.
> 
> Let's get the ball rolling! How do I set up my editor (Notepad) to highlight
> according to Visual C95 syntax?
> 
> FFS. I think you're worse than aminer.

One option is that what you say other is very narrow discussion of the standard
and nothing more

I personally would like the first, discussion ofthe standard is not o much productive imo, sometimes the c programmer need to wrote something in c
Maybe there should be two groups "c language" and "c programming" but i see
only one so i personally think it should encompas the both fields

(personally i am weakly fitted in both now as i am cruising more to langage agnostic topics of game mechanics graphics end more)

[toc] | [prev] | [next] | [standalone]

#57947

On Tue, 03 Mar 2015 01:20:01 -0800, fir wrote:

>> fork() is not a standard C function.  It's defined by POSIX, a secondary
>> standard.  Because of this, you're likely to get better answers if you
>> post to comp.unix.programmer.
> 
> I disagree, some tend to like treat c in extremally narrow way, For me
> even the topics concerning something like game dev or graphics topics
> but in c implementation are on topic here, same as topics of c
> libraries, details of c compilers etc

Even if we accept that, it's not applicable here.

The OP's problem is specifically related to the semantics of the POSIX
fork() system call. The fact that he's using it from C doesn't make the
issue related to C.

[toc] | [prev] | [next] | [standalone]

#57956

W dniu sobota, 7 marca 2015 08:07:15 UTC+1 użytkownik Nobody napisał:
> On Tue, 03 Mar 2015 01:20:01 -0800, fir wrote:
> 
> >> fork() is not a standard C function.  It's defined by POSIX, a secondary
> >> standard.  Because of this, you're likely to get better answers if you
> >> post to comp.unix.programmer.
> > 
> > I disagree, some tend to like treat c in extremally narrow way, For me
> > even the topics concerning something like game dev or graphics topics
> > but in c implementation are on topic here, same as topics of c
> > libraries, details of c compilers etc
> 
> Even if we accept that, it's not applicable here.
> 
> The OP's problem is specifically related to the semantics of the POSIX
> fork() system call. The fact that he's using it from C doesn't make the
> issue related to C.

maybe, i was not readintg that (longer than month im inactive at all/ out of programming), but was saying that "programming in c" is wider and somewhat more productive area than only discussing
the narrow aspects of language over and over

(personally i am much more interested in
the variants of c used today in gpu computing, it is shader c or cuda open cl kernel c, this is really c imo only on new hardware platform - very interesting and new thin worth learning and discussion - but i am not asking here as i suspect it will have no people ere and
will be shunned as offtopic (a bit wrong imo but realy probably such gpu c topics woul have no audience here so i cannot do nothing)

[toc] | [prev] | [next] | [standalone]

#57834

On Monday March 2 2015 18:41, in comp.lang.c, "Ruben Safir"
<mrbrklyn@panix.com> wrote:

> Anyone know why this might not fuction as I thought it might.  It seems
> to start at the beginning of main when a process is forked
> 
> #include <sys/types.h>
> #include <sys/wait.h>
> #include <stdio.h>
> #include <unistd.h>
> #include <stdlib.h>
> 
> 
> int main( int argc, char * argv[]){
>         pid_t pid;
>         pid_t pid_ret;
>         int i = 0;
>         printf("\n___Before the While Loop where Loop is ==> %d__", i);
[snip]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> ___Before the While Loop where Loop is ==> 0__
> Before the Fork in the Loop:
> Loop ==> 1
> 
> Fork: This should print twice for every loop: 1
> 
> Children of the world unite
> Am Yisrael Chai! pid =>0
> Loop in Child ==> 1
> BYE!!
> 
> ___Before the While Loop where Loop is ==> 0__
[snip]

As Keith said, this is off-topic for comp.lang.c, and you'd get a better
explanation from comp.unix.programmer or one of the other Unix groups.

Having said that, take a look at your program. Specifically, the line that
reads
  printf("\n___Before the While Loop where Loop is ==> %d__", i);

Note that, at this point in your code, if you are outputing to a
line-buffered device (such as a console), you /have not/ written the string
out. The next newline (or a call to fflush() ) will flush the buffer, and
cause the string to write out. Such is the way of buffered I/O.

So, prior to the fork(), you have a buffer that contains a string, not
written to stdout.

Consider what happens after the fork(). You now write a newline to stdout,
along with more text. In both the parent process, and the child process.

So, in the parent process, the next newline causes the parent process'
buffer to be flushed, and you see the text
  ___Before the While Loop where Loop is ==> 0__

And, in the child process, which has inherited a copy of the buffer and it's
flags, the next newline causes the child process' buffer to be flushed, and
again, you see
  ___Before the While Loop where Loop is ==> 0__


Such is the way of programming in a Unix multiprogramming environment.
-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#57835

On Monday March 2 2015 19:25, in comp.lang.c, "Lew Pitcher"
<lew.pitcher@digitalfreehold.ca> wrote:

> On Monday March 2 2015 18:41, in comp.lang.c, "Ruben Safir"
> <mrbrklyn@panix.com> wrote:
> 
>> Anyone know why this might not fuction as I thought it might.  It seems
>> to start at the beginning of main when a process is forked
>> 
>> #include <sys/types.h>
>> #include <sys/wait.h>
>> #include <stdio.h>
>> #include <unistd.h>
>> #include <stdlib.h>
>> 
>> 
>> int main( int argc, char * argv[]){
>>         pid_t pid;
>>         pid_t pid_ret;
>>         int i = 0;
>>         printf("\n___Before the While Loop where Loop is ==> %d__", i);
> [snip]
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>> ___Before the While Loop where Loop is ==> 0__
>> Before the Fork in the Loop:
>> Loop ==> 1
>> 
>> Fork: This should print twice for every loop: 1
>> 
>> Children of the world unite
>> Am Yisrael Chai! pid =>0
>> Loop in Child ==> 1
>> BYE!!
>> 
>> ___Before the While Loop where Loop is ==> 0__
> [snip]
> 
> As Keith said, this is off-topic for comp.lang.c, and you'd get a better
> explanation from comp.unix.programmer or one of the other Unix groups.
> 
> Having said that, take a look at your program. Specifically, the line that
> reads
>   printf("\n___Before the While Loop where Loop is ==> %d__", i);
> 
> Note that, at this point in your code, if you are outputing to a
> line-buffered device (such as a console), you /have not/ written the
> string out. The next newline (or a call to fflush() ) will flush the
> buffer, and cause the string to write out. Such is the way of buffered
> I/O.

FWIW, this part is defined in the C standard.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#57841

On Mon, 02 Mar 2015 19:25:48 -0500, Lew Pitcher wrote:

> Having said that, take a look at your program. Specifically, the line
> that reads
>   printf("\n___Before the While Loop where Loop is ==> %d__", i);
> 
> Note that, at this point in your code, if you are outputing to a
> line-buffered device (such as a console), you /have not/ written the
> string out. The next newline (or a call to fflush() ) will flush the
> buffer, and cause the string to write out. Such is the way of buffered
> I/O.
> 
> So, prior to the fork(), you have a buffer that contains a string, not
> written to stdout.

wow - that completely normalized the code. Prior to that I was getting 
almost a recursion affect by parent which was going to be my next 
question.  Now i still have the question but it is a slightly different 
question.

Without the fflush the parent kept rewriting to stdout the whole loop 
over and over again as what is posted here

http://www.nylxs.com/docs/grad_school/operating_systems/output.txt

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
and so on...
Is the buffer being recopied in the parent on every fork?

___Before the While Loop where Loop is ==> 0__
Before the Fork in the Loop:
Loop ==> 1 

Fork: This should print twice for every loop: 1

Children of the world unite
Am Yisrael Chai! pid =>0 
Loop in Child ==> 1 
BYE!!

___Before the While Loop where Loop is ==> 0__
Before the Fork in the Loop:
Loop ==> 1 

Fork: This should print twice for every loop: 1
In the  Parent => I'm waiting 29294
Loop in Parent ==> 1 
Done Waiting for Child

Process that returned was ==> 29294
*******************************

Before the Fork in the Loop:
Loop ==> 2 

Fork: This should print twice for every loop: 2

Children of the world unite
Am Yisrael Chai! pid =>0 
Loop in Child ==> 2 
BYE!!

___Before the While Loop where Loop is ==> 0__
Before the Fork in the Loop:
Loop ==> 1 

Fork: This should print twice for every loop: 1
In the  Parent => I'm waiting 29294
Loop in Parent ==> 1 
Done Waiting for Child

Process that returned was ==> 29294
*******************************

Before the Fork in the Loop:
Loop ==> 2 

Fork: This should print twice for every loop: 2
In the  Parent => I'm waiting 29295
Loop in Parent ==> 2 
Done Waiting for Child

Process that returned was ==> 29295
*******************************

Before the Fork in the Loop:
Loop ==> 3 

Fork: This should print twice for every loop: 3

Children of the world unite
Am Yisrael Chai! pid =>0 
Loop in Child ==> 3 
BYE!!

___Before the While Loop where Loop is ==> 0__
Before the Fork in the Loop:
Loop ==> 1 

Fork: This should print twice for every loop: 1
In the  Parent => I'm waiting 29294
Loop in Parent ==> 1 
Done Waiting for Child

Process that returned was ==> 29294
*******************************

Before the Fork in the Loop:
Loop ==> 2 

Fork: This should print twice for every loop: 2
In the  Parent => I'm waiting 29295
Loop in Parent ==> 2 
Done Waiting for Child

Process that returned was ==> 29295
*******************************

Before the Fork in the Loop:
Loop ==> 3 

Fork: This should print twice for every loop: 3
In the  Parent => I'm waiting 29296
Loop in Parent ==> 3 
Done Waiting for Child

Process that returned was ==> 29296
*******************************

Before the Fork in the Loop:
Loop ==> 4 

Fork: This should print twice for every loop: 4

Children of the world unite
Am Yisrael Chai! pid =>0 
Loop in Child ==> 4 
BYE!!

___Before the While Loop where Loop is ==> 0__
Before the Fork in the Loop:
Loop ==> 1 

Fork: This should print twice for every loop: 1
In the  Parent => I'm waiting 29294
Loop in Parent ==> 1 
Done Waiting for Child

Process that returned was ==> 29294
*******************************

Before the Fork in the Loop:
Loop ==> 2 

Fork: This should print twice for every loop: 2
In the  Parent => I'm waiting 29295
Loop in Parent ==> 2 
Done Waiting for Child

Process that returned was ==> 29295
*******************************

Before the Fork in the Loop:
Loop ==> 3 

Fork: This should print twice for every loop: 3
In the  Parent => I'm waiting 29296
Loop in Parent ==> 3 
Done Waiting for Child

Process that returned was ==> 29296
*******************************

Before the Fork in the Loop:
Loop ==> 4 

Fork: This should print twice for every loop: 4
In the  Parent => I'm waiting 29297
Loop in Parent ==> 4 
Done Waiting for Child

Process that returned was ==> 29297
*******************************

Before the Fork in the Loop:
Loop ==> 5 

Fork: This should print twice for every loop: 5

Children of the world unite
Am Yisrael Chai! pid =>0 
Loop in Child ==> 5 
BYE!!

[toc] | [prev] | [next] | [standalone]

#57848

ruben <nowhere@nowhere.nor> writes:
[...]
> Is the buffer being recopied in the parent on every fork?
>
> ___Before the While Loop where Loop is ==> 0__
> Before the Fork in the Loop:
> Loop ==> 1 
[...]

fork() is not a standard C function.  It's defined by POSIX, a secondary
standard.  Because of this, you're likely to get better answers if you
post to comp.unix.programmer.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#57899

So the problem should be when many
threads want to print in the same
console output... Right?
If it is printf I  imagine it...
there is only a buffer the treads
want to write in it and flush...
But Is input\output multithreads ?
What one can do if it is not multithread it is use synchronization function every time there is printf(); flush();
Right? 

[toc] | [prev] | [next] | [standalone]

#57900

I wrote: "
But Is input\output multithreads ? 
What one can do if it is not multithread it is use synchronization function every time there is printf(); flush(); 
Right?"
Somethin as in each thread
S(&ioBuf); printf("..."); fflush(stdout); S(&ioBuf);
Where S() is a synchronization function

[toc] | [prev] | [next] | [standalone]

#57901

Forget my posts I don't know what fork() does...

[toc] | [prev] | [next] | [standalone]

#57852

I don't really get what your question is, but I suggest
you don't use printf/puts when multiprocessing,
instead try something like this
(handle==1 for stdout, handle==2 for stderr):

static void mylog (int handle, const char *fmt, ...)
{
     char buff [1024];
     int len;
     va_list ap;

     va_start (ap, fmt);
     len= vsnprintf (buff, sizeof (buff), fmt, ap);
     va_end (ap);
     if (len<0 || (size_t)len>=sizeof (buff)) len= (int)sizeof(buff);
     write (handle, buff, len);
}

Note: if you want to write into file, use append mode
(eg ./myprog >>logfile) not to lose messages.

[toc] | [prev] | [next] | [standalone]

#57855

Lőrinczy Zsigmond <nospam@for.me> writes:
> I don't really get what your question is, but I suggest
> you don't use printf/puts when multiprocessing,
> instead try something like this
> (handle==1 for stdout, handle==2 for stderr):
>
> static void mylog (int handle, const char *fmt, ...)
> {
>     char buff [1024];
>     int len;
>     va_list ap;
>
>     va_start (ap, fmt);
>     len= vsnprintf (buff, sizeof (buff), fmt, ap);
>     va_end (ap);
>     if (len<0 || (size_t)len>=sizeof (buff)) len= (int)sizeof(buff);
>     write (handle, buff, len);
> }
>
> Note: if you want to write into file, use append mode
> (eg ./myprog >>logfile) not to lose messages.

I presume the point of that is to avoid buffering, so output appears
immediately.

What is the advantage of your (POSIX-only) solution over the standard

    printf("Your message here\n");
    fflush(stdout);

?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#57857

On 2015.03.03. 18:44, Keith Thompson wrote:> What is the advantage of 
your (POSIX-only) solution over the standard
 >
 >      printf("Your message here\n");
 >      fflush(stdout);

Afaik, printf/stdio is allowed to write (or more precisely: write(2)) 
characters one-by-one, or line-by-line, or all together, or only store 
until fflush. So printf'd lines may or may not be interleaved.

(Let's also note that its behavior might be different when writing
on terminal and when writing into a file.)

[toc] | [prev] | [next] | [standalone]

#57860

On 03/03/2015 01:06 PM, Lőrinczy Zsigmond wrote:
> On 2015.03.03. 18:44, Keith Thompson wrote:> What is the advantage of 
> your (POSIX-only) solution over the standard
>  >
>  >      printf("Your message here\n");
>  >      fflush(stdout);
> 
> Afaik, printf/stdio is allowed to write (or more precisely: write(2)) 
> characters one-by-one, or line-by-line, or all together, or only store 
> until fflush. So printf'd lines may or may not be interleaved.

The C standard allows three buffering modes: none, line buffered, and
fully buffered (7.21.3p3). You mention four possibilities, and I'm not
sure what the last two correspond with.

> (Let's also note that its behavior might be different when writing
> on terminal and when writing into a file.)

"the ... standard output stream [is] fully buffered if and only if the
stream can be determined not to refer to an interactive device." (7.21.3p7).
Therefore it must be either "unbuffered" or "line buffered". Thus,
whatever you meant by the other two options you listed is allowed (if at
all) only if standard output can be determined to not refer to an
interactive device.

[toc] | [prev] | [next] | [standalone]

#57873

On 2015.03.03. 19:57, James Kuyper wrote:
 > The C standard allows three buffering modes: none, line buffered, and
 > fully buffered (7.21.3p3). You mention four possibilities, and I'm not
 > sure what the last two correspond with.

 > "the ... standard output stream [is] fully buffered if and only if the
 > stream can be determined not to refer to an interactive device." 
(7.21.3p7).
 > Therefore it must be either "unbuffered" or "line buffered". Thus,
 > whatever you meant by the other two options you listed is allowed (if at
 > all) only if standard output can be determined to not refer to an
 > interactive device.

That's very interesting and useful, too. Let's also mention function
setvbuf(3) that lets you configure buffering.

[toc] | [prev] | [next] | [standalone]

#57921

And alternative to setvbuf(3) are pseudo terminals.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web