3

I m learning interprocess communication ...this is the code that bugs me 

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(void)
{
   int pfds[2];
   pipe(pfds);
    if (!fork()) 
    {
       printf("I m the child process\n");
       close(1);  /* close normal stdout */
       dup(pfds[1]);  /* make stdout same as pfds[1] */


       close(pfds[0]); /* we don't need this */
       execlp("ls", "ls", NULL);
 } 
 else 
 {
    printf("I m the parent process\n");
    close(0);       /* close normal stdin */
    dup(pfds[0]);   /* make stdin same as pfds[0] */
    close(pfds[1]); /* we don't need this */
    execlp("wc", "wc", "-l", NULL);
 }
  return 0;

}

These are some of the questions :- 1) I agree that after the execlp() , nothing gets executed , but my printf() statements are before the execlp() , then still why they does not get executed ??

2)The program acts as a pipe command in linux hence it executes like "ls | wc -l" , but how does the system knows to execute the program like "ls | wc -l" and not "wc -l | ls" .. ??

3) I think the 2) question is because i have closed the stdout and used it as my pfds[1] and closed the stdin and used as my pads[0]..but what if the one threads gets exited before the other .. ??

4) (i m using Xcode as well as gcc) , when run the above program in gcc , it works well , but when run in Xcode it shows a "SIGTRAP" and returns "1" in the console

PLZ HELP ...

PS : It would be better if someone tell me how to see execution of the seperate threads in any general problem !! thank you !!

Subbu
  • 2,063
  • 4
  • 29
  • 42
  • For question 2, u already know the answer (from question 3). A pipe works only if it has running threads at both the ends of it. – sr01853 Jan 10 '13 at 07:19

1 Answers1

4

  1. Your printf is being executed. However, it only gets flushed after you redirect stdout, so its output is not shown on the terminal. Try fprintf(stderr, ...) if you want to see it on stderr, or fflush(stdout) before you start messing with file descriptors.

  2. You attach the writing end of the pipe to the stdout of the ls process, and the reading end to stdin on wc, so there's no confusion.

  3. I'm not sure what your concern is here. The ls process exits once it finishes listing the directory, and wc exits once it runs out of input and prints the number of lines. The pipe gets cleaned up automatically once both processes which hold an endpoint have closed it (by exiting).

  4. Hard to say. What does the debugger show? The Xcode debugging environment is primarily aimed at developing and debugging desktop/mobile applications, though, so it's probably just a fluke of some sort.

  • Thank Sir ... for ur great help !! In 3) , i want to ask that , is the "wc -l " waits until the read end of the pipe i.e pfds[0] is completely filled with data....or it just runs independently ??? – Subbu Jan 10 '13 at 07:43
  • even if data is of large size ?? – Subbu Jan 10 '13 at 07:47
  • 1
    Yes. That is, in fact, exactly why this is necessary -- pipes have a limited capacity (typically 4 to 8 kilobytes), so it is necessary for the process on the reading end of a pipe to consume content promptly. –  Jan 10 '13 at 07:48
  • Sir .. is it necessary to use the close(pads[0]) and close(pads[1]) statement in the child and parent process respectively ?? wud it work without that ?? wats the use of it ?? – Subbu Jan 10 '13 at 07:51
  • 1
    It is not necessary, but is a good idea. The extra file descriptor is not used by either of the child processes; it just gets in the way. –  Jan 10 '13 at 07:52