CODEWITHSUNDEEP
c#asp.netvb.netmultithreadingpostback
Stefan Steiger
Stefan Steiger

Reputation: 82306

Aborting a thread in ASP.NET

protected System.Threading.Thread m_searchthread = null;

Question: I've implemented a search algorithm, which a user can start from an ASP.NET website.

When the user clicks on Button "Start", this code is executed:

m_searchthread = new System.Threading.Thread(new System.Threading.ThreadStart(Search));
m_searchthread.IsBackground = true;
m_searchthread.Start();

Now I want to make it possible to abort the search thread. So the user presses on Button "Abort", and this code is executed:

m_searchthread.Abort();

My problem now is: the postback of the abort button resets m_searchthread to NULL...

I am aware of the fact that the thread should be aborted using a flag. The core problem is just: how to stop a thread when you loose all the variables ?

Upvotes: 0

Views: 3579

Answers (5)

Prahlad Yeri
Prahlad Yeri

Reputation: 3663

In order to stop the thread based on a flag, you have to implement in the following manner:

  1. Define the flag itself in a static class or a module where it is accessible to the thread:

    bool StopTheThread = false;

  2. Inside your thread, check for this flag somewhere inside your loop so as to get out of the thread gracefully!

    void SearchProc()
{
    bool exitCond = False;
    while (!exitCond)
    {
        //some execution
        //some execution
        //some execution
        //check for the thread-abort flag:
        if (StopTheThread)
        {
            System.Threading.Thread.Suspend(); //this will suspend the current thread
        }
    }
}

Upvotes: 0

onof
onof

Reputation: 17367

Don't start/stop jobs from a page because is dangerous and you have no control on tasks running and started.

I suggest you to use Quartz.NET. There is a useful answer about using it in Asp.NET: How to use Quartz.net with ASP.NET

Upvotes: 0

Henk Holterman
Henk Holterman

Reputation: 273572

The direct problem here is that you try to use a member variable (field) to store the Thread.

If you store it like Session["MyThreadKey"] = myThread; you at least can get your thread back in the next Postback. Like myThread = Session["MyThreadKey"];

And then you can start to think about a way to avoid Thread.Abort.

You will probably want to wrap the thread in an object that also contains the stop-flag. (and then store that object in Session).

As commented, this will only work on a single-server solution. The better approach all around would be to define a (WCF) service to do the searching.

Upvotes: 1

Adam Houldsworth
Adam Houldsworth

Reputation: 64517

Any variables you want persisted between postbacks need to go into either static variables, view/session state, the ASP.NET cache, or some other form of backing store.

When you postback, you will then need to go and fetch this from whatever backing store you chose.

I'm not attempting to make any comments on how you're performing your async task.

What is happening is your thread variable is local to the page. When the postback occurs, the page life cycle completes and all references to the variable are lost. Each postback triggers a new page life cycle.

You will encounter this problem whenever you have some state residing on the server that you need to remember between postbacks. ViewState is how ASP.NET controls remember their content between postbacks without you needing to repopulate them each time.

Upvotes: 2

James
James

Reputation: 82136

Why not store the flag in the Session or ViewState and do the check in the page load event.

Upvotes: 0

Related Questions