Thread: the fork() instruction

  1. #1
    Eager young mind
    Join Date
    Jun 2006

    the fork() instruction

    hi all,
    I have learnt socket programming through BEEJ's .
    In that sample client/server program that prints the message "hello world " on the client screen once the connetion is established..:
    I cud not inderstand the role of the fork() instruction..
    Can some one help me out??

  2. #2
    Registered User
    Join Date
    Jan 2006
    fork() is a linux call that make a duplicate of the current process. So this would make a separate process to handle the new socket while the current one continues listening. fork() is not available in windows, so you may have to resort to some more complex windows thread programming.

  3. #3
    Eager young mind
    Join Date
    Jun 2006
    yes, i do know how the fork() and exec() procedures work...
    this is the piece of code:

     while(1) { // main accept() loop
           sin_size = sizeof(struct sockaddr_in) ;
           if ((new_fd = accept(sockfd, (struct sockaddr *)&their_addr,&sin_size)) == -1) {
            printf("server: got connection from %s\n ",inet_ntoa(their_addr.sin_addr));
            if (!fork()) { // this is the child process
                    close(sockfd); // child doesn’t need the listener
                     if (send(new_fd, "Hello, world!\n", 14, 0) == -1)
             close(new_fd); // parent doesn’t need this
    I think, the program works even without the fork call, as we two sockets, one for listening and on to tranfer data. So, we can use the send() call immediately after the accept() and there is no need to start another process.. Is,there any significant advantage of using the fork() call though??

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    The edge of the known universe
    > Is,there any significant advantage of using the fork() call though??
    There's a big disadvantage that if you accept a lot of connections quicky, you rapidly run out of process slots in the process table (which is a finite resource).
    Also consider that context switches between processes are considerably more expensive than a function call.

    In the same vein are threads, which seem like a nice idea on the surface are a PITA if threads ever need to share any information. Thread synchronisation problems will make your average malloc problem look like a walk in the park.

    If you want to handle many connections, then read up on the select() function as well. It allows you to monitor many fd's at the same time and return (possibly after a timeout) with those fd's which are either ready to accept more data, or which have data available to be read.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Simulator
    By MasterAchilles in forum C Programming
    Replies: 10
    Last Post: 11-30-2008, 10:31 PM
  2. Fork(), pause(), and storing PID's in a linked list
    By vital101 in forum C Programming
    Replies: 10
    Last Post: 09-28-2007, 02:16 AM
  3. Fork - unpredictable?
    By fredkwok in forum Linux Programming
    Replies: 4
    Last Post: 03-26-2006, 02:49 PM
  4. fork(), exit() - few questions!
    By s3t3c in forum C Programming
    Replies: 10
    Last Post: 11-30-2004, 06:58 AM
  5. Daemon programming: allocated memory vs. fork()
    By twisgabak in forum Linux Programming
    Replies: 2
    Last Post: 09-25-2003, 02:53 PM