Imagine it this way: Look at your code. Pretend that immediately after the fork, a layer of clear paper, representing the child process, has been set down over your code. Both pages have a moveable marker on them, right after the fork. Now, the markers, which represent program execution flow, proceed independently. On the original page, the fork has succeeded and returned a child process id*, so the next if test directs execution back to the while loop expression. On the new clear page, however, the fork as return 0, the next if test fails, and execution proceeds until the exit is reached. The fact that you're in a loop is incidental.

*Two problems here: First, it's possible for fork() to return undef if it wasn't possible to fork. Second, if fork() does succeed, you'll want to save the child process so that you can reap it when the child process exits. See perlipc in the on-line Perl docs for the full story plus examples.