Understanding fire and forget when using infinite loops

Question

Can someone tell me what the best practice/proper way of doing this is?
I'm also using WPF, not a console or ASP.NET.

Using Listener to accept clients and spin off a new "thread" for each client that handles all the I/O and Exception catching for that client.

Method 1: Fire and forget, and just throw it into a variable to get rid of the warning.

public static async Task Start(CancellationToken token)
{
    m_server = TcpListener.Create(33777);
    m_server.Start();
    running = true;
    clientCount = 0;

    // TODO: Add try... catch
    while (!token.IsCancellationRequested)
    {
        var client = await m_server.AcceptTcpClientAsync().ConfigureAwait(false);

        Client c = new Client(client);

        var _ = HandleClientAsync(c);
    }
}

Here's the Client Handler code:

public static async Task HandleClientAsync(Client c)
{
    // TODO: add try...catch
    while (c.connected)
    {
        string data = await c.reader.ReadLineAsync();

        // Now we will parse the data and update variables accordingly
        // Just Regex and some parsing that updates variables
        ParseAndUpdate(data);
    }
}

Method 2: The same thing... but with Task.Run()

var _ = Task.Run(() => HandleClientAsync());

Method 3: an intermediate non async function (doubt this is good. Should be Async all the way)
But this at least gets rid of the squiggly line without using the variable trick which kinda feels dirty.

while (!token.IsCancellationRequested)
{
    var client = await m_server.AcceptTcpClientAsync().ConfigureAwait(false);

    Client c = new Client(client);

    NonAsync(c);
}

public static void NonAsync(VClient vc)
{
    Task.Run(() => HandleClientAsync(vc));
}

Method 4: Make HandleClientAsync an Async void instead of Async Task (really bad)

public static async Task HandleClientAsync(Client c)
// Would change to
public static async Void HandleClientAsync(Client c)

Questions:

• Is it any better to use Task.Run() When doing a fire and forget task?
• Is it just accepted that you need to use the var _ = FireAndForget() trick to do fire and forget? I could just ignore the warning but something feels wrong about it.
• If I wanted to update my UI from a Client, how would I do that? Would I just use a dispatcher?

Thanks guys

Answer 1

I've never been a fan of background workers which you expect to run for a long time, being run in a task. Tasks get scheduled to run on threads drawn from a pool. As you schedule these long running tasks, the thread pool gets smaller and smaller. Eventually all of the threads from the pool are busy running your tasks, and things get really slow and unmanageable.

My recommendation here? Use the Thread class and manage them yourselves. In this way, you keep your thread pool and the overhead for for tasks out of the picture.

Addendum - Producer Consumer Model

Another interesting question to consider: Do you really need a thread for every client? Threads are reasonably costly to create and maintain in terms of memory overhead, and if your client interaction is such that the client threads spend the vast majority of their time waiting around on something to do, then perhaps a producer consumer model is more suited to your use case.

Example:

• Client connects on listening thread, gets put in a client queue
• Worker thread responsible for checking to see if the clients need anything comes along through that queue every so often and checks - does the client have a new message to service? If so, it services all messages the client has, then moves on

In this way, you limit the number of threads working to just the number needed to manage the message queue. You can even get fancy and add worker threads dynamically based on how long its been since all the clients have been serviced.

If you insist

If you really like what you have going, I suggest refactoring what youre doing a bit so that rather than HandleClientAsync you do something more akin to CreateServiceForClient(c);

This could be a synchronous method that returns something like a ClientService. ClientService could then create the task that does what your HandleClientAsync does now, and store that task as a member. It could also provide methods like ClientService.WaitUntilEnd() and ClientService.Disconnect() (which could set a cancellation token, also stored as a member variable)