What should I use to make an application that will:
Ask the user for username and password
Authorize
Run an infinite loop in which it will fetch some data from the website every 10 seconds or so.
I want to be able to do some basic tasks in the meantime, or lock my screen without the thread getting killed. I don't want the service to continue running after I close the application, I just want to be sure the thread is never killed while it's running for a long time.
I also wanted to ask: Are services as easy to interact with as threads? Can I just pass a CancellationToken in it and cancel it when the user presses the stop button?
I also found the setThreadPriority, will it help in my case?
Services and Threads are totally different concepts. A Thread is a separate process that executes in parallel. A Service is a component of an app that doesn't have a UI and runs with a separate life cycle. A service does not run on its own thread, it runs on the UI thread (although it can launch a Thread if it wishes).
You use a Service if you want to do some task but not be bound to the Android Activity lifecycle. You use a Thread if you want to run in parallel. If you want both, then you use a Service that launches a Thread.
From what I'm reading (you don't want the Thread to continue after the Activity is finished), you want a Thread and not a Service.
A service can run in isolation (while your app is not necessarily running). A thread can be spun off from either your app itself, or a service.
Related
My program uses a producer/consumer pattern, meaning that my producer adds tasks to a queue and my consumer executes those tasks in the background whenever there's something in the queue to execute.
My worker thread needs to use a serial port, and the standard way of using a serial port is to open it at the start of the program and keep it open for as long as it's needed (until shutdown). My program is an always-on web service, where usually objects have a lifetime scoped to the request. These two things contradict each other somewhat, so I need to make sure that when I get a request, the background thread is up and running and holding the serial port open instead of opening it for every request which might be more natural in most cases. So my program needs a high degree of self-sufficiency, it needs to detect errors in the worker thread and restart it if needed.
Is there a technique for guaranteeing that my worker thread stays up? I have considered wrapping the entire worker thread's code in a try/catch, and sending an event to the main thread in the finally block so that the worker can be restarted. Or I could continually send "ping" events to the main thread to let it know that the worker thread is still running, or even poll the worker thread from the main thread.
Is there a standard way of doing this? What's the most robust approach? Note that it's fine if the worker thread dies or becomes unable to complete its work for whatever reason - I will just restart the thread and keep trying, however ideally if that happens it should be able to put its task back in the queue.
Examples in C#/F#/dotnet (framework) are greatly appreciated.
I'm building a web application in Asp.net. I have long-running tasks that may or may not get finished, as IIS tends to kill long running tasks.
Problem? Nope. I use quartz to periodically restart tasks that die (as changes get saved in the DB, so all we need to do is restart the thread).
But now I'm trying to build my web-application to support scaling out. I'd like to run multiple instances.
So, to handle my long running tasks, I'm thinking of adding a column to my database to note which instance has 'checked out' a given task. However, I'll need to know when the thread dies so that I can make sure it's 'checked in'.
So how do I check when a thread dies?
IIS does not kill threads, it kills AppDomains. The only way I know would be have it write a entry as a heartbeat signal while it is running. If the heartbeat has stopped the thread died.
I'm creating an application that's going to be continuously listening out for incoming signals via TCP until it's either stopped via a button, or the application closes. Being as the PC that the application is running on needs to run quite CPU-heavy stuff, I figured I should run this in a separate thread so that it doesn't hog the CPU.
My thoughts are to use a BackgroundWorker containing an inner-loop in DoWork() that checks the IsCancellationPending flag (this is set via the CancelAsync() method when the user clicks the stop button or exits the application). Is this the best route to go, or is there some other method that's more accepted?
You're doing an IO bound operation, so you shouldn't even be using another thread at all. You should be handling the work asynchronously, in which an event, callback, Task, etc. fires to indicate that you have a message to process, which you can process and then go back to not using any thread at all.
Creating a thread that's just going to spend the vast majority of its time sitting there doing nothing while you wait for network activity isn't a productive use of resources.
I need a block of code which run a job in background. Suppose the user click on the Submit button, then a job starts in background, in the mean time the user closes that window and run a different job, and the job should keep running.
Please provide some help in ASP.NET and VB.NET.
Thank You Very Much For Your Help
You may take a look at the ThreadPool.QueueUserWorkItem method which allows you to run some some method on a thread drawn from the thread pool. As an alternative you could use the Thread class to spawn a new thread manually if it is a long running task to avoid jeopardizing a thread from the pool which contains a limited number of threads and which are also used to service requests in ASP.NET applications.
You can do this by creating a windows service that host a wcf service, when the user click on the submit button you can send the request to the windows service and the windows service will run in the background event the user closes the window.
A BackgroundWorker may be the easiest place to start. Put your code in the DoWork event.
You might use the BackgroundWorker, depending on your context.
BackgroundWorker will run in the background and can be easily used to sync back updates to your GUI if needed.
Or use the Task Parallel Library...
Ok, so i have Call1 in a webservice that will start a bacground worker thread to start doing some processing, but would like to have another call (Call2) that will monitor the original Worker Thread via a reference?
Any suggestions on how to do this? I'd really like to stay away from a WinService to do my processing. As i need it to be more realtime.
I don't see why using a Service application should be a problem. Services run all the time and monitoring them can be done it real time.
But, if you really don't want to go that way then there are other options. It is possible to start a new thread, using the ThreadPool or by starting a new Thread manually, and that thread will run in the background of the application pool where your web service runs.
You may want to use a task scheduler library for this. Check out Quartz.net for this.
Be aware that the app domain where your web service runs may be killed at any time if IIS decides it is necessary, so there is no guarantee that the job will complete. Using a Service application will fix this.