0
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 ?

Abel
  • 56,041
  • 24
  • 146
  • 247
Stefan Steiger
  • 78,642
  • 66
  • 377
  • 442
  • 3
    Instead of bolding what you are aware of, could you post the code of your algorithm so that it can be improved in order to use a flag? The core of the problem is your algorithm, not the fact that you are loosing variables on Postback (this is the normal behavior of an ASP.NET page) – Darin Dimitrov Jul 27 '10 at 10:04
  • 2
    Please don't use

    that way, I removed it. Use \* for emphasis instead.

    – Abel Jul 27 '10 at 10:08
  • Using a flag is pretty simple, it's a while loop... The problem is just that a flag for a thread will wrongly stop the thread on postback. – Stefan Steiger Jul 27 '10 at 10:21
  • You may be aware that you shouldn't use Thread.Abort but not everyone else in the world is. Pointing out that it isn't good practise is still useful and relevant to this topic. – Phil Gan Jul 27 '10 at 10:24

5 Answers5

2

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.

Adam Houldsworth
  • 63,413
  • 11
  • 150
  • 187
  • Yea, you say it: It's not possible without static variables. Which is a very very very bad idea indeed. – Stefan Steiger Jul 27 '10 at 11:24
  • @Quandary I'm trying not to place any opinions on the use of any server state - I don't do enough ASP.NET to have worthwhile input :), so I'll take your word for it. – Adam Houldsworth Jul 27 '10 at 12:30
1

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.

H H
  • 263,252
  • 30
  • 330
  • 514
  • `Thread` is not `[Serializable]` so I wouldn't recommend this approach. The day you decide to use a server farm and out-of process session storage this code won't work. – Darin Dimitrov Jul 27 '10 at 10:09
  • @Darin: correct, but the threaded search won't work at all this way on a server farm. – H H Jul 27 '10 at 10:12
  • I agree. I need to do it as external service and have a UID stored in a session variable, with which I can call the external service to stop the thread with that UID. – Stefan Steiger Jul 28 '10 at 06:39
0

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

James
  • 80,725
  • 18
  • 167
  • 237
  • 1
    `Thread` is not `[Serializable]` so I wouldn't recommend this approach. The day you decide to use a server farm and out-of process session storage this code won't work. – Darin Dimitrov Jul 27 '10 at 10:10
  • @Darin: Yeah seen your comment I changed my answer back to ignore storing the thread in the session. – James Jul 27 '10 at 10:11
0

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

Community
  • 1
  • 1
onof
  • 17,167
  • 7
  • 49
  • 85
0

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
            }
        }
    }
    
takrl
  • 6,356
  • 3
  • 60
  • 69
Prahlad Yeri
  • 3,567
  • 4
  • 25
  • 55