1

I have this simple code in aspnet :assuming no exceptions nor file locking nor process terminates :

    new Thread(()=>{
          Thread.sleep(15000);
         // GC.Collect(); 
          File.Write (...); // dummy file

    }).Start();

   // GC.Collect();

From my tests , the file is always created.

Question

   
The scenario which is not understood to me is that the request lifetime is much shorter than thread execution and still it works . Thats all . Thats my main question  

Is it always guaranteed that the file will be created ?

Nb it's just a test to examine behavior . Also the page is an empty page with only this code. Also i know that join will wait

Royi Namir
  • 144,742
  • 138
  • 468
  • 792
  • 2
    It's not clear what you think *might* happen to stop that from being the case. Yes, the process could be killed. Yes, there might be an asynchronous exception. Yes, the file might be in use elsewhere. No, the executing thread won't be garbage collected - is that *actually* what you were worried about? If so, please make it clear in the question. – Jon Skeet Jun 23 '14 at 08:42
  • Jon , edited .assuming No exceptions and no locking – Royi Namir Jun 23 '14 at 08:47
  • 1
    So again, what alternative are you considering? If you're worried about garbage collection, as your code *implies*, you should say so. – Jon Skeet Jun 23 '14 at 08:47
  • If there are no exceptions or other problems, where are you concerned of? – Patrick Hofman Jun 23 '14 at 08:48
  • Jon , patrick - the scenario which is not understood to me is that the request lifetime is much shorter than thread execution and still it works . Thats all . Thats my main question – Royi Namir Jun 23 '14 at 08:52
  • Ps sorry I'm typing via mobile – Royi Namir Jun 23 '14 at 08:55

2 Answers2

2

It is not. When IIS decides to recyle the entire process it will take down both background and foreground threads. See this answer.

Luckily, you can make sure they are not interrupted. You can tell ASP.NET about your thread by implementing the IRegisteredObject interface. You can then register your object using HostingEnvironment.RegisterObject. See The Dangers of Implementing Recurring Background Tasks In ASP.NET

Community
  • 1
  • 1
dcastro
  • 66,540
  • 21
  • 145
  • 155
  • @RoyiNamir I've found a source regarding foreground threads - see my updated answer. – dcastro Jun 23 '14 at 08:48
  • Can you explain how come - changing it to backgroundThread=true - still works ? shouldn't main request terminates all sub threads ? – Royi Namir Jun 23 '14 at 18:44
  • Also - how do you explain this ? it's contridict my test : http://stackoverflow.com/questions/23483091/why-asp-net-kills-my-background-thread – Royi Namir Jun 23 '14 at 19:09
  • @RoyiNamir ASP.NET does not necessarily kill all background/foreground threads (that you've created) when a request ends. It might, but it doesn't necessarily happen after *every* request. – dcastro Jun 24 '14 at 09:58
1

Unless the thread is aborted or the above statements throw exceptions, yes, it will always be created (leaving file permissions and IO problems out of the picture).

Reasons the thread might be aborted:

  • (Manual) application pool recycle;
  • Request abandoned;
  • Crash of application.
Patrick Hofman
  • 153,850
  • 22
  • 249
  • 325