-Pierre > On Sep 26, 2017, at 1:57 PM, Jean-Daniel <[email protected]> wrote: > > > >> Le 26 sept. 2017 à 22:38, Pierre Habouzit <[email protected] >> <mailto:[email protected]>> a écrit : >> >>> On Sep 26, 2017, at 11:22 AM, Jean-Daniel via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>>> Le 26 sept. 2017 à 00:13, Adam Kemp <[email protected] >>>> <mailto:[email protected]>> a écrit : >>>> >>>>> On Sep 25, 2017, at 3:04 PM, Jean-Daniel via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>>> Le 25 sept. 2017 à 21:42, John McCall via swift-evolution >>>>>> <[email protected] <mailto:[email protected]>> a écrit : >>>>>> >>>>>> 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. >> > > I’m glade to be wrong about that point ;-) > One issue I still see is what should be the default when running on a bare > pthread outside of any queue context. Or is there a queue associated with any > thread ?
My thinking is that we need to have a notion of "current place to run swift bullshi^Wclosures". It could be the current queue if there's one, or the current CFRunLoop (if there's one already made) It could be the current "libfoobar event loop", ... and if there's neither, then I think it would be completely appropriate to crash at runtime because it means you made a thread without the Swift runtime knowledge without any setup to allow running swift actors/asyncs/... on it and then called into Swift code that needs it. In less joking tones, what I was thinking about is that the runtime should be able to have a way to get to the "current actor/async/.... context" for a thread which is an object that implements a given protocol that has the necessary methods to receive asyncs/actors/... I hope I'm making sense. -Pierre
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
