<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><br style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Le 26 sept. 2017 à 00:13, Adam Kemp <<a href="mailto:adam_kemp@apple.com" class="">adam_kemp@apple.com</a>> a écrit :<br class=""><br class=""><blockquote type="cite" class="">On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><br class="">This doesn't have to be the case, actually. The intrinsics as Chris described them wouldn't be sufficient, but you could require a "current queue" to be provided when kicking off an async function from scratch, as well as any other "async-local" context information you wanted (e.g. QoS and the other things that Dispatch tracks with attributes/flags that are generally supposed to persist across an entire async operation).<br class=""><br class=""></blockquote><br class="">My response was about the ‘implicitly’ part. I hope we will get a rich API that let us specify return queue, QoS and more, but how do you plan to fulfill the « current queue » requirement implicitly ?<br class=""></blockquote><br class="">My earlier response to this thread both linked to a previous thread about this and explained how C# does it. It will require some library support, but it can be done, and IMO should be done. As I’ve stressed repeatedly, async/await without this behavior will be very difficult to use correctly. I really hope we don’t settle for that.<br class=""></blockquote><br style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">In C#, the model is far simple as there is not concept of a single dispatch queue that can execute work on any thread. You can easily use TLS to store a default context. Each UI thread can have a context that dispatch completion on the message queue, but AFAIK,</span></div></blockquote><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""> there is not DispatchQueue Local Storage yet.</span></div></blockquote><div><br class=""></div><div>There is, see dispatch_queue*_specific()</div><br class=""><blockquote type="cite" class=""><div class=""><span style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""> Even something as simple as getting the current queue is not reliable (see dispatch_get_current_queue man page for details).</span><br style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><div><br class=""></div><div>This is a sharp construct for clients, but not for the runtime / compiler that can be taught how not to fall in the traps of this API.</div><div><br class=""></div><div>Just to debunk myths, dispatch_get_current_queue() is VERY WELL defined, but has two major issues: nesting & refcounting.</div><div><br class=""></div><div><br class=""></div><div><b class="">Nesting</b></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><br class=""></div><div>Nesting refers to the fact that when you call code that takes a queue and a callback, you may observe *another* queue:</div></div><div><div><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div>run_something_and_call_me_back(arg1, arg2, on_queue, ^{</div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div><b class=""> assert(dispatch_get_current_queue() == on_queue); // may crash</b></div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div> ... my stuff ...</div></div></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><div>});</div></div></blockquote><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">The reason is that run_something_and_call_me_back() may create a queue that targets `on_queue` and then this private queue is what is returned which is both unexpected and exposing internals of the implementation of run_something_and_call_me_back() which is all wrong.</blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><br class=""></blockquote><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">A corollary is that people attempting to implement recursive locking (which is a bad idea in general anyway) with dispatch_get_current_queue() will fail miserably.</blockquote><div class=""><br class=""></div><b class="">Refcounting</b><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class=""><div>Because dispatch has a notion of internal refcount, in ARC world, this will crash most of the time:</div></div><div><br class=""></div><div>dispatch_async(dispatch_queue_create_with_target("foo", NULL, NULL), ^{</div><div> <b class="">__strong</b> dispatch_queue cq = dispatch_get_current_queue(); <b class="">// will usually crash with a resurrection error</b></div><div>});</div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div>These two edges is why we deprecated this interface for humans.<div class=""><br class=""></div><div class="">1) A compiler though is not affected by the first issue because the context it would capture would have to not be programatically accessible to clients</div><div class="">2) The Swift runtime can know to take "internal" refcounts when capturing this hidden pointer and is not affected by the second problem either.<br class=""><div class=""><br class=""></div><div class=""><br class=""></div><div class="">tl;dr: what is badly defined is allowing clients to get a pointer to the current queue with a real +1, but that is WAY stronger than what the language runtime needs.</div><div class=""><br class=""></div><br class=""><div class=""><div><blockquote type="cite" class=""><div class=""><span style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">That’s why I’m saying it will be difficult to define a reasonable default context that can be used implicitly.</span><br style="font-family: SFMono-Light; font-size: 11px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote><br class=""></div><div>This is just not true. This is both easy and reasonable.</div><br class=""><div class=""><br class=""></div><div class=""><div class="">
-Pierre
</div>
<div><br class=""><blockquote type="cite" class=""></blockquote></div></div></div></div></body></html>