Shared fd after a fork()

This is a discussion on Shared fd after a fork() within the Linux Programming forums, part of the Platform Specific Boards category; Hello guys, I've seen examples as follows: Code: int pfds[2]; char buf[30]; pipe(pfds); if (!fork()) { printf(" CHILD: writing to ...

  1. #1
    Registered User
    Join Date
    Mar 2009
    Posts
    37

    Shared fd after a fork()

    Hello guys,

    I've seen examples as follows:
    Code:
        int pfds[2];
        char buf[30];
        pipe(pfds);
        if (!fork()) {
            printf(" CHILD: writing to the pipe\n");
            close(pfds[0]);
            write(pfds[1], "test", 5);
            printf(" CHILD: exiting\n");
            exit(0);
        } else {
            printf("PARENT: reading from pipe\n");
            read(pfds[0], buf, 5);
            printf("PARENT: read \"%s\"\n", buf);
            wait(NULL);
        }
    So the childprocess gets a copy of filedescriptors from the parents. But if the child closes a pfds[0], won't that pfds[0] in the parent process be useless? (appearently not!)
    It's a bit confusing to me, cause I thought closing a filedescriptor, will close also one end of the pipe.

    Thank you.

  2. #2
    Super Moderator
    Join Date
    Sep 2001
    Posts
    4,913
    My understanding is that when the child receives a copy, it's completely duplicated - the memory pointed to by pointers is also duplicated (that's why malloc'ed memory can't be shared between two process). So the two file descriptors, even though they reference the same 'file', are completely separate entities. One can indeed be closed, and the other would still work. Pipes are intended to work this way. The parent process closes the end it doesn't use --only as far as the parent process is concerned--, and the child process does the same --only as far as the child process is concerned--.

    That's why you need file locking and things like that - because 2 different programs can access the same file in 2 different ways - pipes included, I guess!

  3. #3
    Registered User
    Join Date
    Mar 2009
    Posts
    37
    Sean,

    Thank you for your reply.
    I now understand that after forking the filedescriptor will be duplicated, it's like calling the dup() function, right. But you say that pointers are also duplicated, meaning that the address pointed to the malloc'ed memory will be the same (like normal variables have the same value as the parent form the moment the child is being forked).

    So I don't really understand your line "that's why malloc'ed memory can't be shared between two process". Cause as long as the pointer (whatever pointer it is) holds the address of a malloc'ed memory, I can reach it from everywhere (theoretically). Unless the kernel provided me my own peace of memory which is isolated from the others, so the malloc'ed mem-address is more kind of relative address?

    So how can I share, for example, my own defined structure between childprocesses, if I can't use the pointer to it (without discussing the synchronization stuff like semaphore)?

    Thank you, sorry for the silly questions, I really do read a book about it, but I still need some time to understand the concept, as I was used to work with ready made MFC classes for windose. Thumbs down

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by Andaluz View Post
    Cause as long as the pointer (whatever pointer it is) holds the address of a malloc'ed memory, I can reach it from everywhere (theoretically).
    Absolutely not true. You can run two processes simultaneously that spit out the memory addresses they are using and try and feed them back into one another, but under no circumstances will the OS allow you access to someone else's memory in any way.

    As to file descriptors, the first one you open is usually 3 -- you don't really believe that is file descriptor #3 for the whole computer system, do you? With pipe then fork, the two processes both have descriptors referring to the same system file (an anonymous pipe). It's a good idea to close opposite ends so the OS doesn't lock them both in the same place.
    Last edited by MK27; 03-20-2009 at 03:21 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 7
    Last Post: 02-06-2009, 11:27 AM
  2. fork(), exit() - few questions!
    By s3t3c in forum C Programming
    Replies: 10
    Last Post: 11-30-2004, 05:58 AM
  3. Writing input from a file into shared memory
    By RazielX in forum C Programming
    Replies: 2
    Last Post: 09-23-2004, 12:34 PM
  4. Resource ICONs
    By gbaker in forum Windows Programming
    Replies: 4
    Last Post: 12-15-2003, 06:18 AM
  5. Managing shared memory lookups
    By clancyPC in forum Linux Programming
    Replies: 0
    Last Post: 10-08-2003, 04:44 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21