[swift-corelibs-dev] qos_class_self()

[Daniel A. Steffen]

> On Feb 8, 2016, at 13:10, Drew Crawford <drew at sealedabstract.com> wrote:
> 
> 
>> On Feb 8, 2016, at 1:00 PM, Daniel A. Steffen <dsteffen at apple.com <mailto:dsteffen at apple.com>> wrote:
>> 
>> if we need it to be, it might make sense to add support for some of the QoS accessor APIs to the libdispatch Linux port, but I’m not convinced we should be replicating any of the related non-portable functionality until QoS works on Linux more generally (in particular QoS overrides would need kernel support and without that, support for QoS in libdispatch doesn’t make very much sense in the first place given that it will just lead to priority inversions).
> 
> I would argue that we should stub qos_class_self now, and decide how to implement it later.
> 
> This is because I use the API defensively, e.g. here is a real example:
> 
>         //ensure that the operation does not exceed the current priority
>         dispatch_async(dispatch_get_global_queue(qos_class_self(), 0)) {[unowned self] () -> Void in
>             self.readMessageIntoBuffer()
>         }
> 

on Darwin, dispatch_async does this for you already if you use the default global queue, there is no need to specify this information in this way (dispatch_async propagates QoS automatically and applies it if the queue submitted to has unspecified QoS or is the default global queue)

> If QOS is not implemented, then this codelisting is still correct.
> 
> However if QOS becomes implemented someday, and I have in the meantime rewritten this code not to use qos_class_self (because it wasn't available) then the code is probably incorrect, because it no longer avoids the priority inversion.
> 
> In other words, I think there is value in giving GCD this information even if it isn't prepared to make use of it.  When it someday becomes prepared, programs will already be compatible.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-corelibs-dev/attachments/20160208/1e16069d/attachment.html>