c# - Calling async methods from a Windows Service

Question

I have a Windows Service written in C# that periodically fires off background jobs. Typically, at any given time, several dozen heavily I/O bound Tasks (downloading large files, etc) are running in parallel. The service runs on a relatively busy web server (necessary for now), and I think it could benefit greatly in terms of thread conservation to use asynchronous APIs as much as possible.

Most of this work is done. All jobs are now fully async (leveraging HttpClient, etc.), as is the main job loop (with heavy doses of Task.Delay). All that's left is to figure out how to correctly and safely fire up the main loop from the service's OnStart. Essentialy, it's the much-warned-about calling-async-from-sync dilemma. Below is what I have so far (grossly simplified).

in Program.cs:

static void Main(string[] args) {
    TaskScheduler.UnobservedTaskException += (sender, e) => {
        // log & alert!
        e.SetObserved();
    };
    ServiceBase.Run(new MyService());
}

in MyService.cs:

protected override void OnStart(string[] args) {
    _scheduler.StartLoopAsync(); // fire and forget! will this get me into trouble?
}

It's that call to StartLoopAsync that concerns me. I can't simply Wait() on the returned Task because OnStart needs to return relatively quickly. (Job loops need to run on a separate thread.) A couple thoughts come to mind:

• Am I well covered as far as unobserved exceptions by placing that handler in Main?
• Would there be any benefit to using Task.Run, something like Task.Run(() => _scheduler.StartLoopAsync().Wait()); ?
• Would there be any benefit to calling _scheduler.StartLoopAsync().ConfigureAwait(false) here? (I'm doubting it since there's no await here.)
• Would there be any benefit to using Stephen Cleary's AsyncContextThread in this situation? I haven't seen any examples of using this, and since I'm starting an infinite loop I don't know that syncing back up to some context is even relevant here.

Answer 1

UnobservedTaskException will be called for all unobserved Task exceptions, so it's a good place for logging like this. However, it's not great because, depending on your program logic, you may see spurious messages; e.g., if you Task.WhenAny and then ignore the slower task, then a any exceptions from that slower task should be ignored but they do get sent to UnobservedTaskException. As an alternative, consider placing a ContinueWith on your top-level task (the one returned from StartLoopAsync).

Your call to StartLoopAsync looks fine to me, assuming it's properly asynchronous. You could use TaskRun (e.g., Task.Run(() => _scheduler.StartLoopAsync()) - no Wait is necessary), but the only benefit would be if StartLoopAsync itself could raise an exception (as opposed to faulting its returned task) or if it took too long before the first await.

ConfigureAwait(false) is only useful when doing an await, as you surmised.

My AsyncContextThread is designed for this kind of situation, but it was also designed to be very simple. :) AsyncContextThread provides an independent thread with a main loop similar to your scheduler, complete with a TaskScheduler, TaskFactory, and SynchronizationContext. However, it is simple: it only uses a single thread, and all of the scheduling/context points back to that same thread. I like that because it greatly simplifies thread safety concerns while also allowing concurrent asynchronous operations - but it is not making full use of the thread pool so, e.g., CPU-bound work would block the main loop (similar to a UI thread scenario).

In your situation, it sounds like AsyncContextThread may let you remove/simplify some of the code you've already written. But on the other hand, it is not multithreaded like your solution is.