Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Are background threads a bad idea? Why?

So I've been told what I'm doing here is wrong, but I'm not sure why.

I have a webpage that imports a CSV file with document numbers to perform an expensive operation on. I've put the expensive operation into a background thread to prevent it from blocking the application. Here's what I have in a nutshell.

protected void ButtonUpload_Click(object sender, EventArgs e)
{
    if (FileUploadCSV.HasFile)
    {
        string fileText;
        using (var sr = new StreamReader(FileUploadCSV.FileContent))
        {
            fileText = sr.ReadToEnd();
        }

        var documentNumbers = fileText.Split(new[] {',', '\n', '\r'}, StringSplitOptions.RemoveEmptyEntries);

        ThreadStart threadStart = () => AnotherClass.ExpensiveOperation(documentNumbers);
        var thread = new Thread(threadStart) {IsBackground = true};
        thread.Start();
    }
}

(obviously with some error checking & messages for users thrown in)

So my three-fold question is:

  • a) Is this a bad idea?
  • b) Why is this a bad idea?
  • c) What would you do instead?
like image 825
Matt Grande Avatar asked May 19 '10 20:05

Matt Grande


People also ask

What is background thread?

Background threads are identical to foreground threads with one exception: a background thread does not keep the managed execution environment running. Once all foreground threads have been stopped in a managed process (where the .exe file is a managed assembly), the system stops all background threads and shuts down.

How many threads are created by the program?

Unless otherwise stated, a program consists of exactly one thread, which is the main thread.

Which threads execute in the foreground (*) by default (*) foreground threads Unlike background ones keep the managed execution environment running?

By default, threads are foreground threads, meaning they keep the application alive for as long as any one of them is running.


1 Answers

A possible problem is that your background thread is running in your web sites application pool. IIS may decide to recycle your application pool causing the expensive operation to be killed before it is done.

I would rather go for an option where I had a separate process, possibly a windows service, that would get the expensive operation requests and perform them outside the asp.net process. Not only would this mean that your expensive operation would survive an application pool restart, but it would also simplify your web application since it didn't have to handle the processing.

Telling the service to perform the expensive process could be done using some sort of inter-process communication, the service could poll a database table or a file, or you could use a management queue that the service would listen to.

There are many ways to do this, but my main point is that you should separate the expensive process from your web application if possible.

like image 113
Rune Grimstad Avatar answered Sep 25 '22 07:09

Rune Grimstad