Calling async methods from a Windows Service

前端 未结 2 765
渐次进展
渐次进展 2020-12-13 04:35

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 fi

相关标签:
2条回答
  • 2020-12-13 05:06

    Not an answer per se, but a year after posting this question we're moving this service to an Azure Cloud Service. I've found the Azure SDK's Worker Role template to be a very good example of properly calling async from sync, providing cancellation support, dealing with exceptions, etc. It's not quite apples-to-apples with Windows Services in that the latter doesn't provide an equivalent to the Run method (you need to kick off your work in OnStart and return immediately), but for what it's worth, here it is:

    public class WorkerRole : RoleEntryPoint
    {
        private readonly CancellationTokenSource cancellationTokenSource = new CancellationTokenSource();
        private readonly ManualResetEvent runCompleteEvent = new ManualResetEvent(false);
    
        public override void Run() {
            Trace.TraceInformation("WorkerRole1 is running");
    
            try {
                this.RunAsync(this.cancellationTokenSource.Token).Wait();
            }
            finally {
                this.runCompleteEvent.Set();
            }
        }
    
        public override bool OnStart() {
            // Set the maximum number of concurrent connections
            ServicePointManager.DefaultConnectionLimit = 12;
    
            // For information on handling configuration changes
            // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.
    
            bool result = base.OnStart();
    
            Trace.TraceInformation("WorkerRole1 has been started");
    
            return result;
        }
    
        public override void OnStop() {
            Trace.TraceInformation("WorkerRole1 is stopping");
    
            this.cancellationTokenSource.Cancel();
            this.runCompleteEvent.WaitOne();
    
            base.OnStop();
    
            Trace.TraceInformation("WorkerRole1 has stopped");
        }
    
        private async Task RunAsync(CancellationToken cancellationToken) {
            // TODO: Replace the following with your own logic.
            while (!cancellationToken.IsCancellationRequested) {
                Trace.TraceInformation("Working");
                await Task.Delay(1000);
            }
        }
    }
    
    0 讨论(0)
  • 2020-12-13 05:08

    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.

    0 讨论(0)
提交回复
热议问题