What you are describing is a scenario where something is doing "work" and a completely separate thing is marking off time for the user. A big problem with this approach, is that what the user is looking at, has no connection with any actual "progress of work". If the "work" grinds to halt due to some extended retry sequence or some program fault, the user is oblivious to this. He just sees some clock continuing to count. This can be especially problematic if your program can run for a "very long time". What's a long time is of course very application dependent.
One of the bad things that can happen is that the user kills the program after awhile even though everything is going just fine. The other problem that can happen is that it takes the user an inordinately long time to come to the conclusion that the program is "hung" and this wastes a lot of time. Both of these scenarios are bad!
I believe that a MUCH better approach is to present the user with some measurement of actual "work progress".
If it is possible, some "percent completed" measurement is great! If not possible, then some measurement like: number of files, number of records, number of directories, etc processed is very good.
Basically there are 2 main objectives: 1) present the user with some on-going status in a "timely" manner. I would suggest something less than every 20 seconds although in some applications say every second is appropriate. 2) This status should have some direct connection to the "work progress".
One of the ways that this is done is to call some subroutine, say: update_status(...) at some major work completion part of your main loop. This sub decides whether to update the user's display or not. You will find that updating a GUI or even writing to the command line is relatively "expensive" and you don't want to do it "too often".
So instead of having some essentially separate thing displaying "elapsed time", you call update_status(...) periodically within your main program at appropriate progress points. This sub has a "time throttle" on it so that it doesn't "go crazy updating info". For example getting current system epoch time is very performant and this sub can just compare current time with last update and decide that it hasn't been a second yet since last user update and it does nothing.
You don't want to call update_status() so often that there is any significant amount of processing power being used, but you want to call it often enough that the user display is getting updated in a "timely manner". Typically this routine is so performant that calling it 100x or even 1,000x per second or even more often makes no difference at all in your app's performance (<0.1%).
I believe that such an approach is FAR superior to some sort of separate timer process.
In reply to Re: Parent process finished. How to exit the child process.
by Marshall
in thread Parent process finished. How to exit the child process.
by ybnormal
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |