[swift-corelibs-dev] qos_class_self()

Drew Crawford drew at sealedabstract.com
Mon Feb 8 15:10:48 CST 2016


> On Feb 8, 2016, at 1:00 PM, Daniel A. Steffen <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()
        }

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/a69b0eaf/attachment.html>


More information about the swift-corelibs-dev mailing list