Quote:
Originally Posted by knc1
Important Disclaimer for the following:
What the copy of busybox does that you might be using may vary from the following, you just have to try it to find out.
Every time you start a background job, that command __should__ return a "job id" number.
Then you can do other things, and when ready to proceed with the result of the background job, do a "wait <job id>".
Which will wait for the background job without the cpu overhead of a busy loop wait for the contents of /tmp/key to change. Where changes to /tmp/key is the expected result of the background job in this example case.
|
Wait is good when your parallel processing tasks are done and you want to wait in a blocking call for background task completion.
But waiting for a keypress this way would stop the foreground process indefinately (until or if a key ever gets pressed). I am doing animation with regular frame updates, so that is not an option. I prefer completing my update cycle, then waiting for a timer event (in a blocking call) until time to begin the next update cycle. A simpler way than timer events is to sleep ALMOST until time to begin the new update cycle, then sync to the timer with a "busy loop" (a/k/a. spinlock).
To conserve energy, you want to sleep as long as possible and busy-loop as short as possible. If you study video game source code, you will see that this is a very popular technique for controlling continuous interactive animation.
This is what most of my demos do (see "usleep(K4DLY)"), which is followed in some code (removed from most published code for simplification) by a "while :;do" loop that calls my getmsec() function to continue at the exact millisecond to begin the next update cycle.
Waiting for a keypress as you suggested can be done a lot easier than calling "wait" with the process ID. You could just call "waitforkey" after your updates are complete and you are ready to wait for a key press.
There are useful reasons to use the "wait" function, but not using to convert a blocking waitforkey call (purposely forked to the background) BACK INTO a blocking waitforkey call is needless complicated, when you could have just called waitforkey in the foreground in the first place.