I have a process running. It should only take 1.5 minutes to run.. but sometimes something happens so at ReadLine it will get stuck. I am processing a video file.. I need a way to kill this process if it goes beyond the 3 min mark. I already have the condition handled if the process is killed.. I thought I could run a timer and after 3 minutes kill the process but ReadLine locks the thread.. this function is running in a thread on my main program..
If you want to run a timer it should be done on a second thread. a Console.ReadLine() will lock up your single thread.
using System.Threading.Timer
This is what I used.. Thanks colton for pointing my the right direction
Dim tmr As New System.Threading.Timer(AddressOf MyTimerTick)
tmr.Change(180000, 0)
Related
I'm using Celery with Django over Redis.
Some of my tasks are quite long, taking about 1 hour. I'm aware that this is suboptimal, and preferably I should use shorter tasks, but this is what I got...
Sometimes the task/worker crash. This can happen for various unimportant reasons. Maybe this worker crashed, network problem, spot-instance when preempted, killed by OOM, or any other unexpected reason that I can't "catch" and handle.
I want to make sure the task will be tried again as fast as possible.
I can use ack_late, but the problem is that this task has a very long timeout (about 90 minutes), which means that if the task started and the worker crashed after 2 minutes, I will now wait for another 88 minutes until the task will get back to the queue and will start executing again on another worker.
I'm wondering if there exists another solution, that will see the worker "disappeared" and will put the task back in the queue?
You could give task_reject_on_worker_lost a try... It is a tricky one, but have a look...
Is time stamp used in process to free its resources if it holds resources for long time ??
if yes then in process state diagram there is no connection between block(wait) state and terminate state but both are connected via running state.so here a anomaly in concept arises that if a process has to quit from wait state then it has to go via running state.
The OS can't indiscriminately kill a process if it holds a resource for a long time.
Would you kill a 24/7 server who waits on a socket?
Would you kill a process who keeps a file opened? After how long? What if the process actually needs to keep the file opened for days? If you think it can't possibly need that much, let me give you this scenario: a computationally intensive process who takes days to compute all it's data. Big data. It uses a file as a "cache/buffer". It writes to it and reads from it continuously. As such it holds the file open all this time.
Would you kill a process who waits on a lock? After how much time? 10 minutes? 1 hour? 10 hours? 5 days? What if the purpose of that process is to do a cleanup or smth after some other process has released the lock, be it if that other process held it for 1 second or for 2 weeks?
I need to have a specific process(method) run once a day at a given time and was wondering if this can be done using the timer control.
As has been stated, if your process isn't already running, then use Task Scheduler to handle this for you.
However, if you have some background service or something already running, then use a timer, and have it check the system time. Timers are not necessarily accurate, and after a day's worth of running, I would expect them to be way off.
Set up a timer with an interval of 3000ms or so, and when that interval hits, then check the system time to see if it is time for your method to run.
You should create a program that does that process, then exits.
You should then schedule the program using Windows Task Scheduler.
How to terminate function/code (not entire page) when it takes some time, for example, more than 1 sec?
If Code > 1 Sec Then
Terminate the code....
I found the command "Server.ScriptTimeou", but it stops the entire page instead of one command.
You can run your function in a background process and start a timer simultaneously. Then abort the process if it runs more than 1 second.
If you want to run in the foreground then you probably have a loop somewhere that is taking a long time. Before you start running, save the current time. Then, somewhere in the middle of the loop, compare the saved time to the current time. When it hits one second, break out of the loop.
The solution will depend on what you're doing. If you're calling a single function that you have no control over and that can sometimes run longer than 1 second or so, you're pretty much stuck with having to run that function on a background thread and then terminate the thread if it runs long.
If you're actually running a long loop, or some other code that you DO have control over, you could just note the current time before starting the process, and in the loop, check if you've run long, and if so, exit the loop.
Just depends.
I have a VB.NET application that uses threads to asynchronously process some tasks in a "Scheduled Task" (console application).
We are limiting this application to run 10 threads at once, like so:
(pseudo-code)
- Create a generic list of 10 threads
- Spawn off the threadproc for each one
- Do a thread.join statement for each thread to wait for the longest running one to complete.
I am finding that if the code called by the threadproc contains any "Debug.Writeline" or "Trace.Traceinformation" statements, the thread hangs. I can see the thread in the Debug - Windows - Threads window and switch to it, but it highlights the Debug.Writeline statement and never gets past it.
Is there something special about the Debug or Trace statements that make them non-thread-safe?
Why would this hang things up? If I leave the debug statement in, the thread never completes. If I take the debug statement out, the thread completes in less than 5 seconds.
Yes and no.
Internally, Debug.WriteLine ends up calling into TraceInternal.WriteLine. This particular function does not explicitly stop thread execution but it does acquire a process global lock during the execution of the method. This lock protects both the list of trace listeners and serializes the processing of WriteLine commands.
It's possible for 2 threads to simultaneously hit this WriteLine statement and hence have one thread pause for a short period of time. It is also possible for a custom trace listener to be doing a very long lived or blocking operation which would essentially freeze all other threads for a noticable period of time.
Use Visual Studio to check and see what other threads are currently broken in this function. See if that gives you a clue as to what is holding up this process.
You may have a trace listener that maybe is interfering with the Debug.WriteLine.
There is a custom trace listener in this application. Once I commented it out, my locking problems were solved. Now if I could only track down the original developer to find out what they were doing with this custom listener...