Understanding Linux Processes 2

[josephstein]

2. Can you spawn independent processes from a C Program using Linux, or are you always going to have the parent/child dependency (using fork() )? I assume that when using the fork() call, if you kill the parent process the child is also killed. Can you create and run 4 totally independent processes from, say a main function, without weeding through several if statements to get to the 4th process? It seems to me that it should be the job of the OS to handle the scheduling of processes without the programmer having to use the if statements.

[hazel]

2. Can you spawn independent processes from a C Program using Linux, or are you always going to have the parent/child dependency (using fork() )? I assume that when using the fork() call, if you kill the parent process the child is also killed. Can you create and run 4 totally independent processes from, say a main function, without weeding through several if statements to get to the 4th process? It seems to me that it should be the job of the OS to handle the scheduling of processes without the programmer having to use the if statements.

Fork() creates a child with its own PID; I should call that independent. If you kill the parent by its PID, that wouldn't affect the child at all. I'm not sure what you mean by your second statement. Why would you want a sequence of if statements? Just use fork() four times.

[Rubberman]

Fork() creates a child with its own PID; I should call that independent. If you kill the parent by its PID, that wouldn't affect the child at all. I'm not sure what you mean by your second statement. Why would you want a sequence of if statements? Just use fork() four times.

Actually, if you kill the parent process, unless the child has either masked SIGHUP or has been nohup'd, then the child will be killed also.

As for the original question:

2. Can you spawn independent processes from a C Program using Linux, or are you always going to have the parent/child dependency (using fork() )? I assume that when using the fork() call, if you kill the parent process the child is also killed. Can you create and run 4 totally independent processes from, say a main function, without weeding through several if statements to get to the 4th process? It seems to me that it should be the job of the OS to handle the scheduling of processes without the programmer having to use the if statements.

All processes are independent. I think you are confusing functions with processes and threads. Yes, the OS does schedule processes and threads as independent entities. Functions or blocks of code within a process or thread are serially executed, conditional statements or branches (if/else/while/for/case) applied.

[hazel]

Actually, if you kill the parent process, unless the child has either masked SIGHUP or has been nohup'd, then the child will be killed also.

That's not always true. For example, if you launch a graphical application from the shell in an xterm and then exit the shell, your app will continue to run. In any case, the child does not die automatically with the parent as the OP seemed to think; it dies (if it dies) because it received a hangup signal from somewhere else (from the kernel maybe?)

[josephstein]

Fork() creates a child with its own PID; I should call that independent. If you kill the parent by its PID, that wouldn't affect the child at all. I'm not sure what you mean by your second statement. Why would you want a sequence of if statements? Just use fork() four times.

The books I have been reading execute the fork() call for in the following way:
ret = fork();
if(ret == 0) then execute child process
else if (ret > 0) execute parent process

If you wanted to spawn more than one child process you would have to nest the fork() calls within the child or parent process.

[Rubberman]

That's not always true. For example, if you launch a graphical application from the shell in an xterm and then exit the shell, your app will continue to run. In any case, the child does not die automatically with the parent as the OP seemed to think; it dies (if it dies) because it received a hangup signal from somewhere else (from the kernel maybe?)

That's because X-Windows (graphical) applications handle or mask those signals. Usually that's done automatically when the GUI libraries initialize the environment. Also, when the windowing environment terminates, GUI shutdown events are sent to any open GUI applications since they can no longer be signaled with SIGHUP events.

[hazel]

The books I have been reading execute the fork() call for in the following way:
ret = fork();
if(ret == 0) then execute child process
else if (ret > 0) execute parent process

If you wanted to spawn more than one child process you would have to nest the fork() calls within the child or parent process.

When fork is run, it creates a process which is initially an exact duplicate of the existing one, except that it has a different PID. Fork returns 0 to the child process, and the child's PID to the parent. Therefore if the return value from fork is zero, you have the child. Usually you then use an exec function to switch execution to a different program. Meanwhile the parent, for which fork returned a positive value, is allowed to continue its current program.

You can then call fork again. It isn't nested; it's a separate call. For example:

ret = fork();
/* Child exits the program at this point */
if (ret == 0) then (execute some other program);
/* Parent continues and spawns another child. The first child never gets to see this code so you don't need an else. */
ret = fork();

[hazel]

@Rubberman
Coincidentally I found this while browsing the libc manual. It describes what happens when a program exits.

"If the process is a session leader that has a controlling terminal, then a SIGHUP signal is sent to each process in the foreground job, and the controlling terminal is disassociated from that session. "

This obviously applies to a shell controlled by a Linux virtual console (ttyn); I guess you are right that it must also apply to a shell on an xterm (pts/n)