how to return a task from execution of list of tasks

Question

I have to write some middle-ware code that requires me to return a Task object. My middle-ware code also uses a framework that asynchronously sends data to a connected client, returning a Task.

Pretty straight forward so far.

However my use case is that I have many connected clients. So my question is basically, what is the most sensible way to call each client's async Send method, and more importantly, what is the Task I should be returning. I'm using c# 5.

class Client // some framework
{
    public Task Send(Object message)
    {
        // does its thing somehow, returns a Task
    }
}


interface Handler<TMessage> // some framework
{
    Task Handle(TMessage msg);
}

class Middleware : Handler<Object> // my middleware implementation code
{
    List<Client> clients;

    public Task Handle(Object msg)
    {
        //i do some stuff here before calling each client's Send method

        return Task.Run(() => clients.ForEach(client => client.Send(msg))); <-- my current solution
    }
}

So in short, I receive a message (the handler), I perform some custom logic (filtering clients etc) and then call each clients async Send method. Depending on the nature of the custom logic which will vary from case to case, I may want to wrap that code inside the Task also. Any advice on this would also be greatly appreciated.

My confusion is, should I be returning the outer Task that I've created as is? Or is there some other preferred way of executing each async method that I'm not aware of.

EDIT:

The Send method is asynchronous even though it's not named SendAsync. Keep in mind it is a framework call, so I can't rename it to SendAsync as suggested. However, rest assured that it is an asynchronous call under the covers, and returns a Task.

Given the truly asynchronous nature of the call, is my usage of:

return Task.Run(() => clients.ForEach(client => client.Send(msg)));

going to cause any issues, given I don't want to wait for each client's asynchronous Send() method to run to completion?

To clarify: by 'cause any issues', I mean is there any cause for concern in simply executing the above? Deadlocks, Exceptions that go unobserved etc..? I ask because I know there are a lot of subtleties in asynchronous programming that aren't always obvious, that someone with a better understanding than me might be able to point out as a possible issue, or perhaps know of a better way to achieve what I'm aiming for...

Answer 1

Since the Send() method is asynchronous and returns a Task, you should do something like this:

public Task Handle(Object msg)
{
    return Task.WhenAll(clients.Select(client => client.Send(msg)));
}

The WhenAll() method will enumerate the sequence of Task objects (projected from the original client values), and return a Task object that represents the completion of all of the client Task objects that were returned.

You should consider changing (or encourage the owner of that code to change) the Send() method's name so that it includes the word Async in it (e.g. SendAsync()). Obviously, the compiler doesn't care what you call the method, but the convention is very useful for easy understanding of asynchronously-based code.

ADDENDUM:

From your revision to the question:

given I don't want to wait for each client's asynchronous Send() method to run to completion?

If you don't want to wait for each client's completion, then just start each operation. There's no reason to use a Task to start the operations:

public void Handle(Object msg)
{
    //i do some stuff here before calling each client's Send method

    clients.ForEach(client => client.Send(msg));
}

By definition, an asynchronous method returns before it's completed. By convention, it will do so quickly. So there should be no need to wrap the execution of the ForEach() in a Task, nor any need for Handle() itself to be asynchronous at all (at least, not for this particular statement in the method).

I mean is there any cause for concern in simply executing the above? Deadlocks, Exceptions that go unobserved etc..?

Certainly you will fail to observe exceptions that occur, at least based on the code you've provided so far.

As for deadlocks, there's no way to know if your code might suffer from that; there's nothing about starting asynchronous operations that in and of itself would create a deadlock scenario, nor would "fire and forget" as you do here add any particular risk of deadlock (if anything, it might reduce the risk, since if you aren't capturing the Task for each operation at all, you obviously can't be synchronously blocking on any of them).