C-style arrays fall through the cracks of the Windows Runtime. We spent the past few days working around the inability to pass them with transfer semantics. Today we look at another hole, namely the inability for them to be the product of an asynchronous operation.<\/p>\n
There is no facility in the Windows Runtime for an As with the inability to transfer ownership of a C-style array, we can work around this by producing an You might try wrapping the array inside a You could create your own wrapper type whose method for producing the C-style array is destructive:<\/p>\n The consuming code would do this:<\/p>\n Another idea is to use the role reversal technique we came up with when dealing with ownership transfer and have the operation complete with a delegate, and then you call the delegate to get the C-style array.<\/p>\n In this case, the consuming code would look like this:<\/p>\n Before digging into the implementation, let’s compare these two strategies.<\/p>\n That’s a trick question. The two strategies are effectively the same!<\/p>\n The similarly is clearer if I rewrite the delegate in terms of what it looks like at the ABI layer:<\/p>\n A delegate is just a class with a single As a result, all that we did was rename So let’s use the delegate version, since it involves less typing, and it also allows us to reuse the On the consuming side, we can avoid the On the producing side, we wrap our return value inside the same sort of delegate we used when we looked at transferring ownership into a class: We move the C-style array into the delegate, and then move it out on request.<\/p>\n We can take advantage of the delegate constructor that takes a lambda and avoid having to repeat the name of the delegate:<\/p>\n Note that it is essential that the C-style array be captured by value into the delegate. The Bonus chatter<\/b>: One customer tried this:<\/p>\n The idea here is that the caller passes in a variable to receive the indices, but the indices don’t actually show up until the Breaking it down a bit more:<\/p>\n This doesn’t work because the The The implementation of For garbage-collected languages, it’s even worse, because even in the absence of errors, garbage collection may run while the And certainly it’s not going to work for marshalled calls, because the server-side implementation receives a server-side So don’t do that. It doesn’t work and corrupts memory.<\/p>\n \u00b9 This isn’t strictly true, but it’s true enough for the purpose of this discussion. Another difference is that delegates derive directly from No good solutions, but some workarounds.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-105999","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":" No good solutions, but some workarounds.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105999","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=105999"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/105999\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=105999"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=105999"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=105999"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}IAsync\u00adOperation<T[]><\/code>. An asynchronous operation can produce a primitive type, a structure type, or a reference type, but not an array.<\/p>\nIBuffer<\/code>, assuming that the underlying type of the array has no destructor. It suffers from the same awkwardness of getting the data into and out of the buffer, as well as limiting yourself to languages that support raw pointers.<\/p>\nProperty\u00adValue<\/code> and using Property\u00adValue.namespace Sample\r\n{\r\n runtimeclass WidgetIndicesHolder\r\n {\r\n Int32[] DetachIndexArray();\r\n }\r\n\r\n runtimeclass Widget\r\n {\r\n \/\/ The \"indices\" array will be very large.\r\n Windows.Foundation.IAsyncOperation<WidgetIndicesHolder>\r\n GetIndicesAsync();\r\n }\r\n}\r\n<\/pre>\nauto holder = co_await widget.GetIndicesAsync();\r\nauto indices = holder.DetachIndexArray();\r\n<\/pre>\n
namespace Sample\r\n{\r\n delegate Int32[] WidgetIndicesProducer();<\/span>\r\n\r\n runtimeclass Widget\r\n {\r\n \/\/ The \"indices\" array will be very large.\r\n Windows.Foundation.IAsyncOperation<WidgetIndicesProducer<\/span>>\r\n GetIndicesAsync();\r\n }\r\n}\r\n<\/pre>\nauto producer = co_await widget.GetIndicesAsync();\r\nauto indices = producer();\r\n<\/pre>\n
namespace Sample\r\n{\r\n runtimeclass WidgetIndicesProducer\r\n {\r\n Int32[] Invoke();\r\n }<\/span>\r\n\r\n runtimeclass Widget\r\n {\r\n \/\/ The \"indices\" array will be very large.\r\n Windows.Foundation.IAsyncOperation<WidgetIndicesProducer>\r\n GetIndicesAsync();\r\n }\r\n}\r\n<\/pre>\nInvoke<\/code> method whose parameters are the delegate parameters and whose return type is the delegate return type.\u00b9 The language projection exposes the Invoke<\/code> method as if it were a function call.<\/p>\nWidget\u00adIndices\u00adHolder<\/code> to Widget\u00adIndices\u00adProducer<\/code> and Detach\u00adIndex\u00adArray<\/code> to Invoke<\/code>.<\/p>\nWidget\u00adIndices\u00adProducer<\/code> delegate that we used to transfer a C-style array into a Windows Runtime class.<\/p>\nproducer<\/code> temporary by invoking the returned delegate immediately.<\/p>\nauto indices = (co_await widget.GetIndicesAsync())();\r\n<\/pre>\n
namespace winrt::Sample::implementation\r\n{\r\n struct Widget : WidgetT<Widget>\r\n {\r\n IAsyncOperation<WidgetIndicesProducer>\r\n GetIndicesAsync()\r\n {\r\n auto result = co_await CalculateIndicesAsync();\r\n co_return WidgetIndicesProducer(\r\n [result = std::move(result)]() mutable\r\n { return std::move(result); });\r\n }\r\n };\r\n}\r\n<\/pre>\nnamespace winrt::Sample::implementation\r\n{\r\n struct Widget : WidgetT<Widget>\r\n {\r\n IAsyncOperation<WidgetIndicesProducer>\r\n GetIndicesAsync()\r\n {\r\n auto result = ... calculate the indices ...\r\n co_return\r\n [result = std::move(result)]() mutable\r\n { return std::move(result); };\r\n }\r\n };\r\n}\r\n<\/pre>\n[&]<\/code> capture is definitely wrong, because the delegate is going to outlive the call to Get\u00adIndices\u00adAsync<\/code>.<\/p>\nnamespace Sample\r\n{\r\n runtimeclass Widget\r\n {\r\n \/\/ The \"indices\" array will be very large.\r\n Windows.Foundation.IAsyncAction GetIndicesAsync(out Int32[] indices);\r\n }\r\n}\r\n<\/pre>\nIAsyncAction<\/code> completes. The intended calling usage would be something like<\/p>\nwinrt::com_array<int32_t> indices;\r\nco_await widget.GetIndicesAsync(indices);\r\n\/\/ use the indices\r\n<\/pre>\n
winrt::com_array<int32_t> indices;\r\nauto action = widget.GetIndicesAsync(indices);\r\n\/\/ indices not yet ready\r\nco_await action;\r\n\/\/ okay, now we have indices\r\n<\/pre>\n
[out]<\/code> parameters are valid only for the lifetime of the call. And the call is done when it returns an IAsyncAction<\/code>.<\/p>\nindices<\/code> may no longer exist by the time the operation completes. For example, during the “indices not yet ready” comment, the caller might decide to go off and do something else, and that other thing might throw an exception, causing everything to unwind and the indices<\/code> to disappear. Or maybe the caller did a wait_for()<\/code> to wait for the indices with a timeout, and if the operation times out, it just gives up. Or maybe the co_await<\/code> threw an exception when trying to register the continuation.<\/p>\nGetIndicesAsync<\/code> doesn’t know that any of these things have happened, and it will happily write to an already-destroyed object, which is a great source of memory corruption.<\/p>\nIAsyncAction<\/code> is pending. The garbage collector might move the out<\/code> parameter or even destroy it completely if the variable is not used after the await<\/code>.<\/p>\nindices<\/code> variable which is marshalled back to the client side when the GetIndicesAsync<\/code> function returns an IAsyncAction<\/code>. COM doesn’t know that “Oh, wait, don’t marshal it back yet. I’m going to update it some more later.”<\/p>\nIUnknown<\/code> rather than from IInspectable<\/code>.<\/p>\n","protected":false},"excerpt":{"rendered":"