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).
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 ?
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.
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,
there is not DispatchQueue Local Storage yet.
There is, see dispatch_queue*_specific()
Even something as simple as getting the current queue is not reliable (see dispatch_get_current_queue man page for details).
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.
Just to debunk myths, dispatch_get_current_queue() is VERY WELL defined, but has two major issues: nesting & refcounting.
Nesting
Nesting refers to the fact that when you call code that takes a queue and a callback, you may observe *another* queue:
run_something_and_call_me_back(arg1, arg2, on_queue, ^{
assert(dispatch_get_current_queue() == on_queue); // may crash
... my stuff ...
});
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.
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.
Refcounting
Because dispatch has a notion of internal refcount, in ARC world, this will crash most of the time:
dispatch_async(dispatch_queue_create_with_target("foo", NULL, NULL), ^{
__strong dispatch_queue cq = dispatch_get_current_queue(); // will usually crash with a resurrection error
});
These two edges is why we deprecated this interface for humans.
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
2) The Swift runtime can know to take "internal" refcounts when capturing this hidden pointer and is not affected by the second problem either.
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.
That’s why I’m saying it will be difficult to define a reasonable default context that can be used implicitly.
This is just not true. This is both easy and reasonable.
-Pierre
···
On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:
Le 26 sept. 2017 à 00:13, Adam Kemp <adam_kemp@apple.com> a écrit :
On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution <swift-evolution@swift.org> wrote:
Le 25 sept. 2017 à 21:42, John McCall via swift-evolution <swift-evolution@swift.org> a écrit :