CODEWITHSUNDEEP
cunixpointersprocessfork
Preston Aoki
Preston Aoki

Reputation: 63

Forks and Pointers in C

Can someone help me understand how the system handles variables that are set before a process makes a fork() call. Below is a small test program I wrote to try understanding what is going on behind the scenes.

I understand that the current state of a process is "cloned", variables included, at the time of the forking. My thought was, that if I malloc'd a 2D array before calling fork, I would need to free the array both in the parent and the child processes.

As you can see from the results below the sample code, the two values act as if they are totally separate from each other, yet they have the exact same address space. I expected that my final result for tmp would be -4 no matter which process completed first.

I am newer to C and Linux, so could someone explain how this is possible? Perhaps the variable tmp becomes a pointer to a pointer which is distinct in each process? Thanks so much.

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

int main()
{
    int tmp = 1;
    pid_t forkReturn= fork();

    if(!forkReturn) {

        /*child*/
        tmp=tmp+5;
        printf("Value for child %d\n",tmp);
        printf("Address for child %p\n",&tmp);
    }

    else if(forkReturn > 0){

        /*parent*/
        tmp=tmp-10;
        printf("Value for parent %d\n",tmp);
        printf("Address for parent %p\n",&tmp);
    }

    else {

        /*Error calling fork*/
        printf("Error calling fork);
    }

    return 0;
}

RESULTS of standard out:

Value for child 6
Address for child 0xbfb478d8
Value for parent -9
Address for parent 0xbfb478d8

Upvotes: 1

Views: 856

Answers (1)

Joshua
Joshua

Reputation: 43317

It did indeed copy the entire address space, and changing memory in the child process does not affect the parent. The key to understanding this is to remember that a pointer can only point to something in your own process, and the copy happens at a lower level.

However, you should not call malloc() or free() at all in the child of fork. This can deadlock (another thread was in malloc() when you called fork()). The only functions safe to call in the child are the ones also listed as safe for signal handlers. I used to be able to claim this was true only if you wrote multithreaded code; however Apple was kind enough to spawn a background thread in the standard library, so the deadlock is real all the time. The child of fork should never be allowed to drop out of the if block. Call _exit to make sure it doesn't.

Upvotes: 2

Related Questions