Does HostingEnvironment.QueueBackgroundWorkItem use an ASP.Net thread pool or another thread pool?

Question

I have an ASP.Net application in which a background task is executed using HostingEnvironment.QueueBackgroundWorkItem , as in the code below.

Question Will the background task be executed in the code below, use a thread from the thread pool of ASP.Net pool or use a thread from a separate thread pool?

public ActionResult SendCustMails() { HostingEnvironment.QueueBackgroundWorkItem(ct => SendCustMailsTo(ct, "Customer Notification")); return View(); } private void SendCustMailsTo (CancellationToken ct, string msg) { //some code is omitted foreach (var customer in Customers) { if (ct.IsCancellationRequested) { break; } SendMail(customer, msg); } return ct; } 

Answer 1

As can be seen from the source code of the hosting environment, the QueueBackgroundWorkItem method uses the _backGroundWorkScheduler field, which is a type of BackgroundWorkScheduler for scheduling background work items:

 public sealed class HostingEnvironment : MarshalByRefObject { //other field declarations private static HostingEnvironment _theHostingEnvironment; private BackgroundWorkScheduler _backgroundWorkScheduler = null; // created on demand //yet more field declarations //methods [SecurityPermission(SecurityAction.LinkDemand, Unrestricted = true)] public static void QueueBackgroundWorkItem(Action<CancellationToken> workItem) { if (workItem == null) { throw new ArgumentNullException("workItem"); } QueueBackgroundWorkItem(ct => { workItem(ct); return _completedTask; }); } // See documentation on the other overload for a general API overview. // // This overload of QueueBackgroundWorkItem takes a Task-returning callback; the // work item will be considered finished when the returned Task transitions to a // terminal state. [SecurityPermission(SecurityAction.LinkDemand, Unrestricted = true)] public static void QueueBackgroundWorkItem(Func<CancellationToken, Task> workItem) { if (workItem == null) { throw new ArgumentNullException("workItem"); } if (_theHostingEnvironment == null) { throw new InvalidOperationException(); // can only be called within an ASP.NET AppDomain } _theHostingEnvironment.QueueBackgroundWorkItemInternal(workItem); } private void QueueBackgroundWorkItemInternal(Func<CancellationToken, Task> workItem) { Debug.Assert(workItem != null); BackgroundWorkScheduler scheduler = Volatile.Read(ref _backgroundWorkScheduler); // If the scheduler doesn't exist, lazily create it, but only allow one instance to ever be published to the backing field if (scheduler == null) { BackgroundWorkScheduler newlyCreatedScheduler = new BackgroundWorkScheduler(UnregisterObject, Misc.WriteUnhandledExceptionToEventLog); scheduler = Interlocked.CompareExchange(ref _backgroundWorkScheduler, newlyCreatedScheduler, null) ?? newlyCreatedScheduler; if (scheduler == newlyCreatedScheduler) { RegisterObject(scheduler); // Only call RegisterObject if we just created the "winning" one } } scheduler.ScheduleWorkItem(workItem); } //yet more methods 

}

And if we look at the source code for BackgroundWorkScheduler :

 internal sealed class BackgroundWorkScheduler : IRegisteredObject { //.... public void ScheduleWorkItem(Func<CancellationToken, Task> workItem) { Debug.Assert(workItem != null); if (_cancellationTokenHelper.IsCancellationRequested) { return; // we're not going to run this work item } // Unsafe* since we want to get rid of Principal and other constructs specific to the current ExecutionContext ThreadPool.UnsafeQueueUserWorkItem(state => { lock (this) { if (_cancellationTokenHelper.IsCancellationRequested) { return; // we're not going to run this work item } else { _numExecutingWorkItems++; } } RunWorkItemImpl((Func<CancellationToken, Task>)state); }, workItem); } //other methods } 

we can see that it internally uses Asp.Net ThreadPool to plan work items.