HostingEnvironment.QueueBackgroundWorkItem uses ASP.Net thread pool or another thread pool?

Question

I have an ASP.Net app, in which a background task runs using HostingEnvironment.QueueBackgroundWorkItem as in code below.

Question: Will the background task scheduled in code below, use a thread from the ASP.Net thread pool thread, or will it 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 Hosting environment source code QueueBackgroundWorkItem method uses _backGroundWorkScheduler field which is type of BackgroundWorkScheduler to schedule 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 to the BackgroundWorkScheduler class's source code:

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 notice that it internally uses Asp.Net ThreadPool to schedule work items.