Introduction

A classic never-ending worker loop can be implemented with Task, but the important part is not the while (true) itself. The important part is cancellation, error handling, and avoiding a busy spin. In modern C# code, a long-running loop should usually watch a CancellationToken and either await work or sleep briefly rather than consuming CPU continuously.

Basic Pattern with Task.Run

A minimal background loop looks like this:

1using System;
2using System.Threading;
3using System.Threading.Tasks;
4
5var cts = new CancellationTokenSource();
6
7Task worker = Task.Run(async () =>
8{
9    while (!cts.Token.IsCancellationRequested)
10    {
11        Console.WriteLine("working");
12        await Task.Delay(1000, cts.Token);
13    }
14}, cts.Token);
15
16await Task.Delay(3000);
17cts.Cancel();
18await worker;

This is the modern equivalent of the old infinite worker thread pattern, but with cooperative shutdown.

Why while (true) Alone Is Not Enough

A raw infinite loop is dangerous if it does not wait for anything.

1while (true)
2{
3    // do nothing
4}

That loop will peg a CPU core. A proper worker loop should either:

• wait for incoming work
• delay between polling attempts
• block on a queue or synchronization primitive

So the real goal is not "never-ending." It is "long-lived and controllable."

Use Cancellation Tokens

The cancellation token is what turns a hard-to-stop infinite loop into a cooperative background worker.

Benefits:

• clean shutdown
• easier integration with application lifetime
• better testability
• fewer abandoned background tasks

Without cancellation, the task may outlive the part of the program that created it.

Prefer Waiting for Real Work

Polling with Task.Delay is acceptable for some jobs, but if work arrives through a queue, waiting on the queue is usually better.

1using System;
2using System.Threading;
3using System.Threading.Channels;
4using System.Threading.Tasks;
5
6var channel = Channel.CreateUnbounded<string>();
7var cts = new CancellationTokenSource();
8
9var worker = Task.Run(async () =>
10{
11    await foreach (var item in channel.Reader.ReadAllAsync(cts.Token))
12    {
13        Console.WriteLine($"Processing {item}");
14    }
15});
16
17await channel.Writer.WriteAsync("job-1");
18await channel.Writer.WriteAsync("job-2");
19channel.Writer.Complete();
20await worker;

This is often better than a timed loop because the task sleeps until work actually exists.

When BackgroundService Is Better

If you are in ASP.NET Core or another hosted environment, a naked Task.Run is often not the best place to manage long-lived background work. A hosted service or BackgroundService gives you lifecycle integration.

That is important because application shutdown, logging, and dependency injection are already wired into the hosting model.

So a good rule is:

• standalone app: Task.Run can be fine
• hosted app: prefer a proper background service abstraction

Handle Exceptions Explicitly

A long-running task that throws unexpectedly can die silently if nobody observes it carefully. Wrap the loop body with clear error handling or ensure the task is awaited and monitored.

That matters even more for endless loops, because the worker may appear healthy until it crashes once and stops forever.

Common Pitfalls

The biggest mistake is using a tight while (true) loop with no waiting, which wastes CPU.

Another mistake is launching a background task with no cancellation path.

A third issue is ignoring exceptions from the worker, which can make the loop die without the rest of the program noticing.

Summary

• A classic never-ending worker loop can be modeled with Task, but it should be cancellable
• Use CancellationToken instead of relying on a raw infinite loop
• Avoid busy spinning; wait for work or delay between polling iterations
• Use queues or hosted background services when the application architecture supports them
• Treat lifecycle and exception handling as part of the design, not as optional cleanup