Parallel processing - continued

Hi,
I am taking up the cue from where I was left in my earlier post ( link given below )

I actually wanted to know the significance of using the Unix "wait" , which returns
the control from background to the current process.
To understand this , I created two scripts , namely
script_1.ksh
script_2.ksh

Here are the codes for the scripts:
script_1.ksh

#!/usr/bin/ksh
for i in {1..4} ;do
   ./script_2.ksh $i &
done
#wait

script_2.ksh

#!/usr/bin/ksh
   echo $1

I need to know why :
a) After the last iteration of the for loop , the shell prompt is NOT returned to the calling script(script_1.ksh) ?
If wait retrieves the control from the last executed BACKGROUND process , then the wait command should have been
called from within the for loop itself so that after every background execution of script_2.ksh for each of the loop
iteration , the control needs to come back to the parent process (script_1.ksh) so that the next iteration could be
processed . And that would effect a sequential execution of the script_2.ksh , and not parallel.

b) Uncommenting the wait command at the end of the for loop in scipt_1.ksh retrieves the control back to the parent process .
Does this mean that the wait command has brought back the control from the last background porcess kicked off when i=4 in
the for loop , and only then will any other subsequent commands in script_1.ksh will be executed. If so , how could the
loop iterated for i=2 and i=3 when it has already send the control to the background by kicking off the script_2.ksh in
its first iteration , and the for loop doesn't have a wait command within itself.
c) The wait command affecting only the latest background process . What about the ones which were spawned earlier ?

Thanks
Kumarjit.

c) wait waits for all child processes to be finished. If the first one submitted takes the longest time, it will wait for that.
a) Issuing a wait after each script background submission annihilates that submission; you could run the script in foreground as well.
b) answers itself from the above.

BTW - unless you have many processors and heavily compute-bound programs, "parallel" background execution should not speed up things (dramatically). The processes will compete for resources as memory or disk, or for locks in DBs.

Thanks RudiC , but I think once an external command (like script_2.ksh) is spawned to the background , the Parent PID for this process would be 1 (i.e., PID of the init process) and not the PID of script_1.ksh . So the parent to whom the status of the background process is returned to would be init , and not the main script.
So how would the wait make script_1.ksh wait for the process/es which aren't it's child after all ????

Regards
Kumarjit.

The parent PID will be the script's PID. Why don't you give it a try and watch & interpret the results?