Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Killing a process after X hours 1
- Thread starter RyanEK
- Start date
You could use the TTimer under the System palette (at least in BDS 2006, I believe it is still located there in all previous versions). After you start the process, start the timer.
Just be sure to note that the timer is in Milliseconds.
And just in case, 1000 milliseconds = 1 second, so apply any needed math to determine how long to set the timer to.
As for killing the child process from Delphi. I am not entirely sure. Have only treaded there from C++, and not from Delphi. So somebody else will have to help out with that half please.
~
Give a man some fire, he will be warm for a day, Set a man on fire, he will be warm for the rest of his life.
Just be sure to note that the timer is in Milliseconds.
And just in case, 1000 milliseconds = 1 second, so apply any needed math to determine how long to set the timer to.
As for killing the child process from Delphi. I am not entirely sure. Have only treaded there from C++, and not from Delphi. So somebody else will have to help out with that half please.
~
Give a man some fire, he will be warm for a day, Set a man on fire, he will be warm for the rest of his life.
-
1
- #3
What I would do is keep a list of times that applications were started at. The list would contain information about where the application lives in memory, as well as what time it was started at.
After every minute or so, depending on how precise you need the application terminated, go through that list and see how long the program has been alive and whether or not its still even in memory. If its exceeded its required life time, then go through the kill process.
The problem with using tTimer is that it uses critical system resources. Depending on the number of applications and timers being used, you could bring the system to its knees relatively quickly.
Another thing that could be done is if the programs this server is launching is something you've coded, you could get these `clients` to be responsible for killing themselves more effectively. This way it can start its own shut down process and clean up its memory use more effectively than just being told to terminate.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
After every minute or so, depending on how precise you need the application terminated, go through that list and see how long the program has been alive and whether or not its still even in memory. If its exceeded its required life time, then go through the kill process.
The problem with using tTimer is that it uses critical system resources. Depending on the number of applications and timers being used, you could bring the system to its knees relatively quickly.
Another thing that could be done is if the programs this server is launching is something you've coded, you could get these `clients` to be responsible for killing themselves more effectively. This way it can start its own shut down process and clean up its memory use more effectively than just being told to terminate.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
- Thread starter
- #4
No problem.
Thinking about the two different methods (Server kill versus client killing itself) is that if you have thousands of child applications running and each of them have a tTimer component on it, you'll still run into resource issues. What you may do if you want to use the idea of having the client terminate itself is just have a variable kick'n around that keeps track of when its started. In a routine thats used the most, or where it makes sense to where it should check if its to kill itself, just do a simple comparison between the current time, and the time it started. Simple math. Kinda.
When using tDateTime, you can take DateTimeEnd-DateTimeStart and get a result. tDatetime works in the way that the date is stored in the integer part of the value (Number before the decimal) and whatever is after the decimal is the PERCENTAGE of the day.
So 0.5 would represent 12:00pm or 12 hours. 0.75 would represent 6:00pm or 18 hours. So on and so on.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
Thinking about the two different methods (Server kill versus client killing itself) is that if you have thousands of child applications running and each of them have a tTimer component on it, you'll still run into resource issues. What you may do if you want to use the idea of having the client terminate itself is just have a variable kick'n around that keeps track of when its started. In a routine thats used the most, or where it makes sense to where it should check if its to kill itself, just do a simple comparison between the current time, and the time it started. Simple math. Kinda.
When using tDateTime, you can take DateTimeEnd-DateTimeStart and get a result. tDatetime works in the way that the date is stored in the integer part of the value (Number before the decimal) and whatever is after the decimal is the PERCENTAGE of the day.
So 0.5 would represent 12:00pm or 12 hours. 0.75 would represent 6:00pm or 18 hours. So on and so on.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
TTimer is not the most efficient way to do this. IMO, the safest way is to drop a TAplicationEvent on your main form.
In Object Inspector "Events" tab, Create an "OnIdle" event. Assuming you trapped the start time, or have updated it after some triggered event, compare StartTime to Now and put your code there. No timer required and no chance of exhausting resources.
This is also a good place to do things like update statusbars, particularly if you want to display the current time in one your statusbar.panel[].
HTH
Roo
Delphi Rules!
In Object Inspector "Events" tab, Create an "OnIdle" event. Assuming you trapped the start time, or have updated it after some triggered event, compare StartTime to Now and put your code there. No timer required and no chance of exhausting resources.
This is also a good place to do things like update statusbars, particularly if you want to display the current time in one your statusbar.panel[].
HTH
Roo
Delphi Rules!
Nice pick, Roo. I was thinking that OnIdle would trigger the last time when put into the background. I wrote up a small app consisting of a form with a tApplications object, put this code in:
Put the application in the background and it kept counting up at a relatively slow pace. Oddly enough though, I changed it from caption:= to application.title:= and the counter went up much MUCH faster.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
Code:
procedure TForm1.ApplicationEvents1Idle(Sender: TObject;
var Done: Boolean);
begin
inc(IdleCount);
caption:=inttostr(idlecount);
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
idlecount:=0;
end;Put the application in the background and it kept counting up at a relatively slow pace. Oddly enough though, I changed it from caption:= to application.title:= and the counter went up much MUCH faster.
-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=-=*=
NEVER send the boss to do a techs job
- Status
Similar threads
- Question
- Question
- Question