When Asp.net terminates background threads?

I was working on a project and there is bulk e-mail sending part of it and when user clicks on the button, he/she gets the "Thanks the e-mails have been sent" immediately as a Response and the same method is firing an async thread as well.

ThreadPool.QueueUserWorkItem(SendEMail, _message);

This thread is queued when user clicks on the send button but since this is default Background Thread I was expecting when the page response ended, this thread would be terminated but it didn't happen because the current thread which fires this Thread was also a Background Thread and a Worker Thread, so which means there is an unfinished foreground thread(s) (Could be MainThread or Worker Threads) still alive but I don't know when they finish because their finish time will effect my background worker threads; When the last foreground thread ends, it causes the process to be terminat开发者_JAVA百科ed, so do background threads.

Should I be afraid of this or Asp.NET can handle it automatically and I am kinda confused because I've read a lot of things about it and now everything is mixed up.

Could you please clarify things a little bit ?

Thanks in advance.

Using the ThreadPool for long-running tasks will negatively influence the performance of your application (because ASP.NET also uses the ThreadPool to handle incoming requests).

Creating threads manually for each task can also become a problem if too much threads are created.

One technique I've used in the past, is to create a custom ThreadPool when starting the application, and enqueuing tasks on that ThreadPool. A simple custom ThreadPool could consist of a single Thread and a Queue of tasks.

When you call QueueUserWorkItem a new thread will be drawn from the thread pool if available and execute the callback function on this thread. If no threads are available, the function will block until a thread is freed. Once it finishes the execution of the method the thread will be suspended and returned to the pool for further reuse. Your only concern should be the fact that threads from the pool are also used to service requests, so if you perform lengthy tasks on them you could jeopardize the whole system request servicing capabilities because there's a limited number of threads in the pool and if all of them are busy performing lengthy operations future HTTP requests will be queued. As an alternative you could consider creating threads manually: new Thread(state => { }).Start();

You can use MSMQ for creating your email queue and have a single thread process the queue.

The following post might be useful as it fits your problem domain. Although it does not use MSMQ but is a good post on processing scheduled tasks using ASP.net.

Simulate a Windows Service using ASP.NET to run scheduled jobs