please help clarify these two fork tests

[Barry Margolin]

In article <slrnbhbl0s.bck.drejcica@sonet.utopija.linux>,
andrej hocevar <andrejh@volja.net> wrote:

>Hello,
>I've been trying to fathom fork() and came up with these two
>programs. I'd like to ask why exactly is it that they behave
>differently? Version 1 will always yield the same output whereas
>version 2 won't. In fact, I wanted to see something like the output
>from the second version -- when I fork(); I expect the program to
>continue with its job and at the same time start a new process with
>its own task. So when the output always comes in the same order, I
>think I must be doing something wrong. Is the waitpid() call still
>blocking? Why are the two tests different?
>If it matters, I'm using Linux.

In version 1, the parent sleeps for 10 seconds before continuing. That
gives the child plenty of time to print its output. So the child's output
will practically always come out first.

In version 2, the OS gets to decide which process should run first.
There's nothing specifying which one has priority, but it doesn't have to
be a random choice, either. For instance, some scheduler designs give more
priority to processes that have used less CPU time recently (this is good
for making interactive applications more responsive when the system is
heavily loaded); a brand-new process, which has used 0 CPU time, would have
priority over its parent for a short while, and this could be enough time
for it to do everything before the parent calls waitpid().

>
>Thanks,
> andrej
>
>test 1:
>================================================= ===================
>#include <sys/types.h>
>#include <sys/wait.h>
>#include <signal.h>
>#include <stdio.h>
>#include <unistd.h>
>
>void myfinish()
>{
> waitpid(-1, NULL, WNOHANG);
>}
>
>int main()
>{
> int i, j, k;
> long x;
>
> struct sigaction MySignalAction;
> MySignalAction.sa_handler = myfinish;
>
> sigaction(SIGCHLD, &MySignalAction, NULL);
>
> for (i = 1; i < 10; i++)
> {
> if (fork() == 0)
> {
> printf("I'm a child\n");
> for (k = 0; k <= 10000; k++);
> _exit(i);
> }
> else
> {
> sleep(10);
> for (j = 1; j <= 10; j++)
> printf("%i ", j);
> printf("\n");
> }
> }
>
> return 0;
>}
>
>test 2
>================================================= ===================
>
>#include <sys/types.h>
>#include <sys/wait.h>
>#include <signal.h>
>#include <stdio.h>
>#include <unistd.h>
>
>int main()
>{
> pid_t pid;
> int i, j, k;
> long x;
>
> for (i = 1; i < 10; i++)
> {
> if (fork() == 0) /* child */
> {
> printf("I'm a child \n");
> for (k = 0; k <= 100000; k++);
> _exit(i);
> }
> else
> {
> while( waitpid(0, NULL, WNOHANG) > 0 ) ;
>
> for (j = 1; j <= 10; j++)
> printf("%i ", j);
> printf("\n");
> }
> }
>
> return 0;
>}
>

--
Barry Margolin, [email]barry.margolin@level3.com[/email]
Level(3), Woburn, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

[David Schwartz]

"Barry Margolin" <barry.margolin@level3.com> wrote in message
news:DllRa.240$0z4.80@news.level3.com...

> the OS gets to decide which process should run first.
> There's nothing specifying which one has priority, but it doesn't have to
> be a random choice, either. For instance, some scheduler designs give

more

> priority to processes that have used less CPU time recently (this is good
> for making interactive applications more responsive when the system is
> heavily loaded); a brand-new process, which has used 0 CPU time, would

have

> priority over its parent for a short while, and this could be enough time
> for it to do everything before the parent calls waitpid().

Some operating systems even deliberately let the child run first in the
hopes that it might complete its job before the parent waits for it.
Personally, I think this is a mistake. Unless a process does something that
requires blocking, or it must be pre-empted because of static priorities or
external events, a process should be allowed to use up its complete
timeslice.

DS