Task.Run vs. QueueUserWorkItem

Using `ThreadPool.QueueUserWorkItem`:

Helps bypass limitations when trying to run async code inside IHttpModule.
Does not interfere with the ASP.NET pipeline.
Email sending does not block the main thread.
Calling SendMailAsync().Wait() is safe here because the operation runs on a separate thread.
The .NET ThreadPool manages a set of worker threads in the background, always on standby.
QueueUserWorkItem submits a task to this pool—if a thread is available, it runs immediately; if not, it’s queued.
That means it does not create a new thread per call, making it lightweight and efficient.

Scope & Behavior:

Feature	QueueUserWorkItem	Task.Run
Nature	Fire-and-forget	Suitable for async/await chains
ASP.NET Web Forms	100% safe and compatible	Compatible, but caution required

Sample usage of ThreadPool.QueueUserWorkItem:

ThreadPool.QueueUserWorkItem(_ =>
{
    try
    {
        PublicFunctions.SendMailAsync(body, to, subject).Wait();
    }
    catch (Exception ex)
    {
        // fallback log
    }
});

About Task.Run:

A task started via Task.Run(...) may not complete before the HTTP response is sent.
If the task takes too long or exceptions pile up, IIS’s thread pool can get overwhelmed.

Task.Run(async () =>
{
    try
    {
        await PublicFunctions.SendMailAsync(...);
    }
    catch (Exception ex)
    {
        // fallback log
    }
});

Which one should you use?

Scenario	Recommendation
Very short and simple tasks	✅ `QueueUserWorkItem`
Targeting .NET 4.0 or earlier	✅ `QueueUserWorkItem`
Involving async/await chains	✅ `Task.Run`

If you're just sending an error email:

The operation is short-lived,
No I/O-heavy logic or file/database writing involved,
It's a fire-and-forget scenario,

Then the simplest, most reliable and performance-friendly choice is:

ThreadPool.QueueUserWorkItem + .Wait()

Why is `QueueUserWorkItem` a smart choice?

Lightweight: No task scheduling overhead, it directly enqueues to the ThreadPool.
Legacy-friendly: 100% compatible with Web Forms and older ASP.NET infrastructure.
Ideal for fire-and-forget: You don’t need the result; you just want to trigger the action.

When would `Task.Run` make more sense?

If the task involves multiple awaits (e.g., send email + log + call API),
If you need to act based on the result of the task,

In summary:

If you're simply sending an error notification email, there's no need to use Task.Run.

The most sensible, lightweight, and battle-tested solution:
ThreadPool.QueueUserWorkItem with .Wait()

Lower resource usage
More predictable behavior
Works perfectly in global error handlers or other rare but critical paths

Task.Run vs. QueueUserWorkItem

Comments

More from this blog

Response.Redirect: true or false?

Optimizing LINQ Queries for SQL Server Bit Fields

Thread was being aborted

Could not load file or assembly X or one of its dependencies.

Using `ThreadPool.QueueUserWorkItem`:

Scope & Behavior:

About Task.Run:

Which one should you use?

If you're just sending an error email:

Why is `QueueUserWorkItem` a smart choice?

When would `Task.Run` make more sense?

In summary:

Command Palette

Comments

More from this blog

Using ThreadPool.QueueUserWorkItem:

Scope & Behavior:

About Task.Run:

Which one should you use?

If you're just sending an error email:

Why is QueueUserWorkItem a smart choice?

When would Task.Run make more sense?

In summary:

Using `ThreadPool.QueueUserWorkItem`:

Why is `QueueUserWorkItem` a smart choice?

When would `Task.Run` make more sense?