{"id":2791,"date":"2015-01-14T13:00:09","date_gmt":"2015-01-14T13:00:09","guid":{"rendered":"http:\/\/writeasync.net\/?p=2791"},"modified":"2015-01-10T17:16:20","modified_gmt":"2015-01-10T17:16:20","slug":"eventhandler-and-asynchrony","status":"publish","type":"post","link":"http:\/\/writeasync.net\/?p=2791","title":{"rendered":"EventHandler and asynchrony"},"content":{"rendered":"

Events in .NET<\/a> are for the most part inherently synchronous multicast delegates<\/a>. It is therefore no surprise that async<\/code> and traditional EventHandler<\/code>-based delegates do not mix<\/a>. Today I’ll illustrate one design approach which I’ve used successfully to get around this incompatibility.<\/p>\n

The scenario (slightly simplified for explanatory purposes) was a looping scheduler of background work items. The scheduler had various lifecycle events such as Draining<\/code> (“waiting for pending work items to complete”), Paused<\/code> (“all further work is on hold for now”), Resuming<\/code> (“preparing to start work items again”), and so on. This scheduler was built to be purely async and as such its inner loop expected to interact only with async-friendly (i.e. non-blocking) code. This of course presented a challenge since the lifecycle events were implemented as good old EventHandler<TEventArgs><\/code><\/a> derivatives.<\/p>\n

One way to “solve” this is by restriction — i.e. no async code allowed for event subscribers. I don’t mean to denigrate this approach because this is actually a very reasonable strategy which could simplify the design. However, in the scenario I’m describing there were at least a few valid use cases which could be concisely implemented by making some calls to a remote server. There surely would have been viable workarounds, perhaps by implementing such logic as a work item itself to be scheduled. But this would have been less straightforward and possibly encourage users of the library to take the relatively easier (but arguably wrong) path of just writing blocking sync code directly in the handler.<\/p>\n

Instead, I got some inspiration from CancelEventArgs<\/code> and the way it allows the user to set<\/em> the Cancel<\/code> property<\/a> to relay information back<\/em> to the event sender. With that in mind, I created this base class AsyncEventArgs<\/code> to maintain a list of async tasks to be scheduled after all handlers were done:<\/p>\n

\r\npublic class AsyncEventArgs : EventArgs\r\n{\r\n    public AsyncEventArgs()\r\n    {\r\n        this.Tasks = new List<Func<Task>>();\r\n    }\r\n\r\n    public IList<Func<Task>> Tasks { get; private set; }\r\n}\r\n<\/pre>\n
Here is a sample use case which invokes a world clock REST API<\/a> to decide whether to stop:<\/p>\n
\r\nDateTime initialTime = await worldClock.GetTimeAsync();\r\nLog("Time is " + TimeString(initialTime));\r\n\r\n\/\/ An infinite loop of successive 100 ms delay tasks\r\nFunc<Task> delayAsync = delegate\r\n{\r\n    Log("Delaying...");\r\n    return Task.Delay(TimeSpan.FromSeconds(0.1d));\r\n};\r\n\r\nLoopingScheduler scheduler = new LoopingScheduler(delayAsync);\r\n\r\nFunc<DateTime, TimeSpan, Task> throwIfMaxDurationAsync = async delegate(DateTime start, TimeSpan duration)\r\n{\r\n    Log("Checking time...");\r\n    DateTime now = await worldClock.GetTimeAsync();\r\n    Log("Time is " + TimeString(now));\r\n    if ((now - start) > duration)\r\n    {\r\n        throw new InvalidOperationException("Max duration reached!");\r\n    }\r\n};\r\n\r\n\/\/ On every pause cycle, check if duration is reached based on world time\r\nscheduler.Paused += delegate(object sender, AsyncEventArgs e)\r\n{\r\n    Log("Paused.");\r\n    e.Tasks.Add(() => throwIfMaxDurationAsync(initialTime, TimeSpan.FromSeconds(2.0d)));\r\n};\r\n\r\nTimeSpan pauseInterval = TimeSpan.FromSeconds(0.5d);\r\nawait scheduler.RunAsync(pauseInterval);\r\n<\/pre>\n
The code is available for your perusal on GitHub: EventHandlerSample<\/a>. Read, use, extend, or modify at will.<\/p>\n","protected":false},"excerpt":{"rendered":"
Events in .NET are for the most part inherently synchronous multicast delegates. It is therefore no surprise that async and traditional EventHandler-based delegates do not mix. Today I’ll illustrate one design approach which I’ve used successfully to get around this… <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[21,91],"tags":[],"class_list":["post-2791","post","type-post","status-publish","format-standard","hentry","category-async","category-design"],"_links":{"self":[{"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts\/2791","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=2791"}],"version-history":[{"count":0,"href":"http:\/\/writeasync.net\/index.php?rest_route=\/wp\/v2\/posts\/2791\/revisions"}],"wp:attachment":[{"href":"http:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=2791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=2791"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/writeasync.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=2791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}