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
···
On May 12, 2016, at 22:29, Zach Waldowski via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Zach Waldowski
zach@waldowski.me <mailto:zach@waldowski.me>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 <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 11, 2016, at 7:09 AM, Matt Wright via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On May 10, 2016, at 11:52 PM, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution