> On May 12, 2016, at 22:29, Zach Waldowski via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > > dispatch_get_context, dispatch_set_context are not around simply in the > absence of blocks. They're just as useful as the queue-specific data APIs as > they have thread-specific storage.
dispatch_get_context and dispatch_set_context are per-object storage of a single word, there is no connection to threads. there are many problems with this API including the lack of synchronization between getters and setters and ill-defined ownership semantics (e.g. a setter replacing an already set context leaks the previous value). On queues this API has been subsumed by the getSpecific/setSpecific API which does not have these problems, for other classes we felt that its drawbacks and problems outweighed the benefits that it provided. Daniel > > Zach Waldowski > [email protected] <mailto:[email protected]> > > > On Thu, May 12, 2016, at 08:50 PM, Pierre Habouzit via swift-evolution wrote: >>> On May 12, 2016, at 10:49 AM, Jose Cheyo Jimenez via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> >>>>> On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> * What is your evaluation of the proposal? >>>>> >>>>> I'm generally in favor of a modernized API overlay like this (and I've >>>>> written something like it myself, albeit much simpler), but I'm hoping >>>>> this proposal can go through another round or two of >>>>> discussion/bikeshedding/revision before approval. >>>>> >>>>> (Small note: I'm really happy about the strong-typed-ness of the Source >>>>> subclasses, e.g. how mergeData is only available for Add/Or.) >>>>> >>>>> In no particular order, here are some things on which I'm unclear, or >>>>> not-so-+1: >>>>> >>>>> - synchronously()'s block parameter should be @noescape. Perhaps more >>>>> arguably, it should have a generic return type and rethrows, like >>>>> autoreleasepool now does. >>>> >>>> Both of these are present in the changes I have for this proposal. The >>>> former point is a mistake in my proposal text, the latter is an >>>> unfortunate oversight on my part in putting together the proposal document. >>>> >>>>> - The names asynchronously(execute:) and synchronously(execute:) don't >>>>> seem to fit with any API guidelines I'm aware of. Did you consider >>>>> including the verb in the method name? >>>> >>>> We did. Of the number of names that we discussed, none of them were >>>> perfect. sync/async are common in other languages but don’t fit the >>>> general direction of the Swift 3 naming conventions. Using >>>> `dispatchAsynchronously` is an extremely long method name, even more so >>>> than `asynchronously`. `perform` does not capture the sync/async nature of >>>> the calls particularly well, compared to DispatchWorkItem where `perform` >>>> immediately executes the block. >>>> >>>>> (And I'm guessing that "func synchronously(work:...)" is meant to be >>>>> "func synchronously(execute work:...)”?) >>>> >>>> Right. >>>> >>>>> As another bikeshed-item, I'd vote for "Data.init(withoutCopying:...)" >>>>> rather than "(bytesNoCopy:...)", and perhaps whenDone() instead of >>>>> notify(). >>>> >>>> Here the init() functions closely mirror Data from Foundation, the >>>> Objective-C class is toll-free bridged to NSData and we desired a close >>>> match to the Foundation Swift API. `notify` is Dispatch-only API though, >>>> I’ll go think over that one. >>>> >>>>> - Are DispatchWorkItemFlags meant to overlay dispatch_block_flags? It >>>>> would be nice to explicitly list these in the proposal. >>>> >>>> The dispatch_block_* API is completely superseded by DispatchWorkItem in >>>> the proposal. DispatchWorkItemFlags is the equivalent to >>>> dispatch_block_flags. >>>> >>>>> - Are functions like dispatch_barrier_sync totally gone in favor of >>>>> passing a .barrier flag? It would be nice to explicitly state this in the >>>>> proposal. >>>> >>>> Yes, you can supply .barrier to either `synchronously` or >>>> `asynchronously`, or create a DispatchWorkItem as a barrier item. Where >>>> possible the multiple variants of a class (dispatch_async, >>>> dispatch_barrier_async, etc) are collapsed into a single method with >>>> default arguments. >>>> >>>>> - I echo Austin's concerns about subclassability. I think it would be >>>>> dangerously misleading if the classes were subclassable from user code, >>>>> even if it didn't work properly. >>>> >>>> Building at compile time will fail. So you wouldn’t get very far trying to >>>> use them, I plan to investigate adding `final` here (it’s only absent for >>>> technical reasons, as the classes originate from Objective-C). >>>> >>>>> - What of the APIs provided on Semaphore and Group objects? I'd like to >>>>> see these before I vote for the proposal. >>>> >>>> These would be transformed similarly, I will include them when updating >>>> the proposal. >>>> >>>> class DispatchSemaphore : DispatchObject { >>>> >>>> >>>> init(value: Int) >>>> >>>> func wait(timeout: DispatchTime = default) -> Int >>>> >>>> func wait(walltime timeout: DispatchWalltime) -> Int >>>> >>>> func signal() -> Int >>>> >>>> } >>>> >>>> class DispatchGroup : DispatchObject { >>>> >>>> init() >>>> >>>> >>>> func wait(timeout: DispatchTime = default) -> Int >>>> >>>> func wait(walltime timeout: DispatchWalltime) -> Int >>>> >>>> func notify(queue: DispatchQueue, block: () -> Void) >>>> >>>> func enter() >>>> >>>> func leave() >>>> >>>> } >>>> >>>> >>>>> - What will dispatch_set_target_queue's replacement look like look like? >>>> >>>> extension DispatchObject { >>>> >>>> >>>> func setTargetQueue(queue: DispatchQueue?) >>>> >>>> } >>>> >>>>> >>>>> - What about dispatch_once? >>>> >>>> Removed. Swift already has lazy initialisation at the language level, >>>> dispatch_once is neither needed nor safe in Swift. >>> >>> Hi Matt, >>> >>> What other API would be removed ? Could the proposal be updated with the >>> API that will not be reachable from the swift wrapper? >>> >>> Thank you. >> >> - dispatch_retain/dispatch_release() that are obviously useless in swift >> - dispatch_get_context/dispatch_set_context() and dispatch_set_finalizer_f() >> because it has no ownership semantics and were only there for ports where >> you had no blocks (as in closures) >> - dispatch_once() and dispatch_once_f() because global initializers do that >> job in swift >> - in general all _f variants, which would be really awkward to use from >> swift anyway >> - anything that was deprecated in previous releases (dispatch_debug, >> dispatch_debugv, dispatch_get_current_queue) as per usual swift import rules >> >> >> -Pierre >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
