fork problem

Discussion in 'C Programming' started by mishra, Jul 19, 2005.

  1. mishra

    mishra Guest

    Hi,
    i thied the following code..
    # include<stdio.h>
    int main()
    {
    int a;
    printf("Hello...");
    a=fork();
    printf("hi\n");
    return(0);
    }

    the o/p is as follows..
    rapti:~/prg [\>] > ./a.out
    Hello... hi
    Hello... hi

    but when i gave
    # include<stdio.h>
    int main()
    {
    int a;
    printf("Hello...\n"); // mark the \n here
    a=fork();
    printf("hi\n");
    return(0);
    }

    the o/p became ..
    rapti:~/prg [\>] > ./a.out
    Hello...
    hi
    hi

    can any one tell me how that \n is affecting?
    and insted of the printf statement if i put some thing else.. that is
    not getting evaluated two times...

    please help me out...
    regard
    Mishra
    mishra, Jul 19, 2005
    #1
    1. Advertising

  2. mishra wrote:
    > Hi,
    > i thied the following code..
    > # include<stdio.h>
    > int main()
    > {
    > int a;
    > printf("Hello...");
    > a=fork();
    > printf("hi\n");
    > return(0);
    > }
    >
    > the o/p is as follows..
    > rapti:~/prg [\>] > ./a.out
    > Hello... hi
    > Hello... hi
    >
    > but when i gave
    > # include<stdio.h>
    > int main()
    > {
    > int a;
    > printf("Hello...\n"); // mark the \n here
    > a=fork();
    > printf("hi\n");
    > return(0);
    > }
    >
    > the o/p became ..
    > rapti:~/prg [\>] > ./a.out
    > Hello...
    > hi
    > hi
    >
    > can any one tell me how that \n is affecting?
    > and insted of the printf statement if i put some thing else.. that is
    > not getting evaluated two times...


    Looks like printf is buffering data until it gets a newline. As you fork
    the original process the data for printf is also copied to the new
    context, and so you see the data appear twice.
    If you would change this you could try using unbuffered output.

    Kind regards,
    Johan

    --
    o o o o o o o . . . _____J_o_h_a_n___B_o_r_k_h_u_i_s___
    o _____ || http://www.borkhuis.com |
    .][__n_n_|DD[ ====_____ | 4all.nl |
    >(________|__|_[_________]_|________________________________|

    _/oo OOOOO oo` ooo ooo 'o!o!o o!o!o`
    == VxWorks-page: http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html ==
    Johan Borkhuis, Jul 19, 2005
    #2
    1. Advertising

  3. mishra

    Guest

    Ok,

    If remember correctly (I', sure you'll let me know if not!):

    '\n' causes the stdout buffer to be flushed, i.e. as soon as '\n' is
    parsed the contents will, in this case, be displayed on screen. In the
    first example you don't flush the buffer so 'Hello' will still be in
    the buffer waiting to be outputted. fork () returns twice, once as the
    parent process and once as the child process. The child process's
    memory will be a copy of the parent process's memory (i.e. both
    processes will have the same data in memory), so a copy of stdout's
    buffer (which contains "Hello") will exist for both processes. When
    you then go on to send "hi\n" to stdout the buffer is flushed causing
    "Hello" to be displayed by both the parent and the child.

    In order to better understand how fork () works you should be checking
    it's return value (remembering that it returns twice) so that you can
    print whether you are in the parent or the child.

    Nick
    , Jul 19, 2005
    #3
  4. mishra

    Antonio Guest

    mishra wrote:
    > Hi,
    > i thied the following code..
    > # include<stdio.h>
    > int main()
    > {
    > int a;
    > printf("Hello...");
    > a=fork();
    > printf("hi\n");
    > return(0);
    > }
    >
    > the o/p is as follows..
    > rapti:~/prg [\>] > ./a.out
    > Hello... hi
    > Hello... hi
    >
    > but when i gave
    > # include<stdio.h>
    > int main()
    > {
    > int a;
    > printf("Hello...\n"); // mark the \n here
    > a=fork();
    > printf("hi\n");
    > return(0);
    > }
    >
    > the o/p became ..
    > rapti:~/prg [\>] > ./a.out
    > Hello...
    > hi
    > hi
    >
    > can any one tell me how that \n is affecting?
    > and insted of the printf statement if i put some thing else.. that is
    > not getting evaluated two times...
    >
    > please help me out...
    > regard
    > Mishra


    This is my first post here, but I think I can help there. This strange
    behaviour is caused because of the way that stdout behaves. Stdout is
    line buffered, wich means that when you write to it, in truth you're
    writting to a buffer that doesn't get "flushed" until a new line
    character is written to the buffer.

    In your first example, you write to stdout, but don't place any new
    line character, so the actual write to console is delayed. Then you
    make a fork, wich creates a copy of the process, including the buffer
    to stdout. When you make the second printf, the buffer is flushed, so
    both processes write the same to stdout.

    In the second example, since there is a new line character in the first
    printf, the buffer has been flushed, and so both processes after the
    fork have an empty buffer to stdout.

    So to summarize, the first printf is only executed once, as would be
    any sentence that you could place before the fork. But it's effects are
    replicated by the line buffering of stdout.

    Hope that helped.
    Antonio, Jul 19, 2005
    #4
  5. mishra

    SM Ryan Guest

    # This is my first post here, but I think I can help there. This strange
    # behaviour is caused because of the way that stdout behaves. Stdout is
    # line buffered, wich means that when you write to it, in truth you're

    In this case, it is almost certainly line bufferred, but that does not
    have to be generally true of stdout. To force the bufferring behaviour,
    use the setvbuf function.

    As a general rule, force stdio buffer flushes of all writable FILEs
    before forking. You can also use fflush for this.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    No pleasure, no rapture, no exquisite sin greater than central air.
    SM Ryan, Jul 19, 2005
    #5
  6. "mishra" <> writes:
    > i thied the following code..
    > # include<stdio.h>
    > int main()
    > {
    > int a;
    > printf("Hello...");
    > a=fork();
    > printf("hi\n");
    > return(0);
    > }
    >
    > the o/p is as follows..
    > rapti:~/prg [\>] > ./a.out
    > Hello... hi
    > Hello... hi

    [snip]

    There is no fork() function in standard C. Try comp.unix.programmer
    (where they'll tell you, among other things, that you should #include
    the proper system-specific header before using fork().)

    If you invoked your compiler properly, it should warn you that fork()
    is undeclared. If you're using gcc, try "gcc -ansi -pedantic -W -Wall";
    change "-ansi" to "-std=c99" if you want to take advantage gcc's
    incomplete C99 support. If you're using a compiler other than gcc,
    check its documentation.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Jul 19, 2005
    #6
  7. mishra

    Jack Klein Guest

    On 19 Jul 2005 05:23:58 -0700, "Antonio" <> wrote in
    comp.lang.c:

    > mishra wrote:
    > > Hi,
    > > i thied the following code..
    > > # include<stdio.h>
    > > int main()
    > > {
    > > int a;
    > > printf("Hello...");
    > > a=fork();
    > > printf("hi\n");
    > > return(0);
    > > }
    > >
    > > the o/p is as follows..
    > > rapti:~/prg [\>] > ./a.out
    > > Hello... hi
    > > Hello... hi
    > >
    > > but when i gave
    > > # include<stdio.h>
    > > int main()
    > > {
    > > int a;
    > > printf("Hello...\n"); // mark the \n here
    > > a=fork();
    > > printf("hi\n");
    > > return(0);
    > > }
    > >
    > > the o/p became ..
    > > rapti:~/prg [\>] > ./a.out
    > > Hello...
    > > hi
    > > hi
    > >
    > > can any one tell me how that \n is affecting?
    > > and insted of the printf statement if i put some thing else.. that is
    > > not getting evaluated two times...
    > >
    > > please help me out...
    > > regard
    > > Mishra

    >
    > This is my first post here, but I think I can help there.


    Since it's your first post here, I'll point this out:

    The question is off-topic and any attempts to answer it in detail are
    off-topic. The topic of this newsgroup is the C language, which is
    specifically and completely defined originally by the two editions of
    K&R, then, since 1989, by various ANSI/ISO International Standards.

    fork() is not part of the C language or its libraries. It is a
    non-standard (from the point of the language and this newsgroup)
    extension provided by some particular compiler and operating system
    combinations.

    The UNIX API does not define the C language. The Windows API does not
    define the C language.

    In cases like this, the only appropriate reply is to redirect the
    poster to a group where his question is topical, if one knows of one.
    In this case news:comp.unix.programmer would be a good choice.

    --
    Jack Klein
    Home: http://JK-Technology.Com
    FAQs for
    comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
    comp.lang.c++ http://www.parashift.com/c -faq-lite/
    alt.comp.lang.learn.c-c++
    http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
    Jack Klein, Jul 20, 2005
    #7
  8. mishra

    SM Ryan Guest

    Jack Klein <> wrote:

    # The question is off-topic and any attempts to answer it in detail are

    It is most definitely on-topic unless you think setbuffer, setvbuf,
    printf, stdout, and _everything_ else in <stdio.h> is off-topic.
    The question is about how does stdio bufferring work, not how does
    fork work. A similar issue would show up if the program aborts and
    appears to lose part of the output: until you know some output can
    be bufferred and unknown to the operating system, you won't understand
    what setvbuf refers to.

    # fork() is not part of the C language or its libraries. It is a

    As usual, two mistakes: "C language" is not ANSI C. Second, you see
    "fork" and your knee jerks without pausing to understand the true
    problem, which is how ANSI C file bufferring and interact with program
    execution.

    # The UNIX API does not define the C language. The Windows API does not
    # define the C language.

    ANSI <stdio.h> does not define the language.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    I have no respect for people with no shopping agenda.
    SM Ryan, Jul 20, 2005
    #8
  9. Re: forkin' problem

    In article <>,
    SM Ryan <> wrote:
    ....
    >ANSI <stdio.h> does not define the language.


    It should be clear by now that Jack Klein defines the language.
    Kenny McCormack, Jul 20, 2005
    #9
  10. SM Ryan wrote:
    > Jack Klein <> wrote:
    >
    > # The question is off-topic and any attempts to answer it in detail are
    >
    > It is most definitely on-topic unless you think setbuffer, setvbuf,
    > printf, stdout, and _everything_ else in <stdio.h> is off-topic.
    > The question is about how does stdio bufferring work, not how does
    > fork work. A similar issue would show up if the program aborts and
    > appears to lose part of the output: until you know some output can
    > be bufferred and unknown to the operating system, you won't understand
    > what setvbuf refers to.
    >
    > # fork() is not part of the C language or its libraries. It is a
    >
    > As usual, two mistakes: "C language" is not ANSI C.


    It is in this group, but as usual you still can't seem to comprehend
    this.

    > Second, you see "fork" and your knee jerks without pausing to understand the > true problem, which is how ANSI C file bufferring and interact with program
    > execution.


    The use of fork() plays a large part in the behavior being discussed
    and a group like comp.unix.programmer would be a much more appropriate
    place for this post. Jack was completely correct in what he said and
    he couldn't have been more helpful or polite with his reply.

    Robert Gamble
    Robert Gamble, Jul 20, 2005
    #10
  11. mishra

    CBFalconer Guest

    Re: forkin' problem

    Kenny McCormack wrote:
    > SM Ryan <> wrote:
    > ...
    >> ANSI <stdio.h> does not define the language.

    >
    > It should be clear by now that Jack Klein defines the language.


    You neglected to quote Jacks informative paragraph, which follows:

    >>> The question is off-topic and any attempts to answer it in detail
    >>> are off-topic. The topic of this newsgroup is the C language,
    >>> which is specifically and completely defined originally by the
    >>> two editions of K&R, then, since 1989, by various ANSI/ISO
    >>> International Standards.


    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Jul 20, 2005
    #11
  12. mishra

    Antonio Guest

    Robert Gamble wrote:
    > SM Ryan wrote:
    > > As usual, two mistakes: "C language" is not ANSI C.

    >
    > It is in this group, but as usual you still can't seem to comprehend
    > this.


    <flame>
    Then this group should be renamed to something along the lines of
    comp.lang.c.ansi or comp.lang.ansic
    </flame>

    In case anyone doubts it, the flame was intended to be a joke...
    Antonio, Jul 20, 2005
    #12
  13. mishra

    CBFalconer Guest

    Robert Gamble wrote:
    > SM Ryan wrote:
    >> Jack Klein <> wrote:
    >>

    .... snip ...
    >>
    >># fork() is not part of the C language or its libraries. It is a
    >>
    >> As usual, two mistakes: "C language" is not ANSI C.

    >
    > It is in this group, but as usual you still can't seem to
    > comprehend this.
    >
    >> Second, you see "fork" and your knee jerks without pausing to
    >> understand the true problem, which is how ANSI C file bufferring
    >> and interact with program execution.

    >
    > The use of fork() plays a large part in the behavior being discussed
    > and a group like comp.unix.programmer would be a much more appropriate
    > place for this post. Jack was completely correct in what he said and
    > he couldn't have been more helpful or polite with his reply.


    As contrasted to Ryans continuous childish attempts to foul normal
    newsreaders by insisting on his non-standard quote mark. It is
    best to treat him as a pure troll, and PLONK him. This reduces the
    annoyance factor and thence the blood pressure.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Jul 20, 2005
    #13
  14. mishra

    CBFalconer Guest

    Antonio wrote:
    > Robert Gamble wrote:
    >> SM Ryan wrote:

    >
    >>> As usual, two mistakes: "C language" is not ANSI C.

    >>
    >> It is in this group, but as usual you still can't seem to
    >> comprehend this.

    >
    > <flame>
    > Then this group should be renamed to something along the lines
    > of comp.lang.c.ansi or comp.lang.ansic
    > </flame>
    >
    > In case anyone doubts it, the flame was intended to be a joke...


    Unfortunately there are those among us who would take it
    seriously. They are often the same people that flout other useful
    standards for no reason other than to annoy. We who restrict the
    definition have at least 6 references available:

    K&R I
    K&R II
    C89
    C90
    C95
    C99

    all of which can be fairly readily found, and all of which build on
    previous work. Most of these have, at one time or another, been
    stamped as "THE STANDARD" by national and international
    organizations. Before recommending anything else, be sure it is
    equally accepted and applicable. For example Posix is an OS
    standard, not a language standard. Many systems can use the C
    language that can never even approach the Posix standard.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
    CBFalconer, Jul 20, 2005
    #14
  15. mishra

    SM Ryan Guest

    "Robert Gamble" <> wrote:

    # The use of fork() plays a large part in the behavior being discussed

    Your knee is jerking too. fork demonstrates the problem in this case,
    but the underlying issue is not fork, but has stdio bufferring works.

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    You hate people.
    But I love gatherings. Isn't it ironic.
    SM Ryan, Jul 21, 2005
    #15
  16. mishra

    SM Ryan Guest

    Re: forkin' problem

    # You neglected to quote Jacks informative paragraph, which follows:
    #
    # >>> which is specifically and completely defined originally by the
    # >>> two editions of K&R, then, since 1989, by various ANSI/ISO

    Maybe you should re-read K&R 1978 pp 158-177 (chapter 8).

    --
    SM Ryan http://www.rawbw.com/~wyrmwif/
    This is one wacky game show.
    SM Ryan, Jul 21, 2005
    #16
  17. Re: forkin' problem

    On Thu, 21 Jul 2005 05:13:48 -0000, SM Ryan
    <> wrote:

    ># You neglected to quote Jacks informative paragraph, which follows:
    >#
    ># >>> which is specifically and completely defined originally by the
    ># >>> two editions of K&R, then, since 1989, by various ANSI/ISO
    >
    >Maybe you should re-read K&R 1978 pp 158-177 (chapter 8).


    You mean the one that says this chapter applies only to Unix.


    <<Remove the del for email>>
    Barry Schwarz, Jul 22, 2005
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Patrick
    Replies:
    1
    Views:
    509
  2. Small Fork Problem

    , Mar 5, 2007, in forum: C Programming
    Replies:
    3
    Views:
    308
    Martin Ambuhl
    Mar 5, 2007
  3. CMorgan
    Replies:
    3
    Views:
    354
    suresh shenoy
    Jan 2, 2008
  4. bugbear
    Replies:
    4
    Views:
    2,888
    Arne Vajhøj
    Mar 28, 2008
  5. Eric Snow

    os.fork and pty.fork

    Eric Snow, Jan 8, 2009, in forum: Python
    Replies:
    0
    Views:
    560
    Eric Snow
    Jan 8, 2009
Loading...

Share This Page