LibDispatch : access to current queue, or queue name

Hi everyone,

With the release of swift 3, The interface to libDispatch has evolved quite a lot, to a much cleaner, object oriented interface.
There seems to be one feature that is no longer available :
In swift 2, it was possible to get the current queue label using "dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL)".

In the new interface, the DispatchQueue has a label property, but there seems to be no way to get the current queue.

Is that a design decision ?
If not, a "current" class property should probably be added to "DispatchQueue".
If yes, maybe we could add a "currentQueueLabel" class property to "DispatchQueue", but this doesn't look right to me : why should only this property of the current queue be available, and not other ones like "qos" ?

This comes a bit late, I'm sorry for not spotting that when SE-0088 was being reviewed !

Jerome Duquennoy

1 Like

With the release of swift 3, The interface to libDispatch has evolved quite a lot, to a much cleaner, object oriented interface.
There seems to be one feature that is no longer available :
In swift 2, it was possible to get the current queue label using "dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL)".

In the new interface, the DispatchQueue has a label property, but there seems to be no way to get the current queue.

Is that a design decision ?

[Cc: Matt Wright]

If not, a "current" class property should probably be added to "DispatchQueue".

`DispatchQueue.current` is unlikely to be accepted, because `dispatch_get_current_queue()` is deprecated (since iOS 6.0, macOS 10.9).

If yes, maybe we could add a "currentQueueLabel" class property to "DispatchQueue", but this doesn't look right to me : why should only this property of the current queue be available, and not other ones like "qos" ?

`DispatchQueue.currentQueueLabel` might be useful for debugging and logging. Or maybe this would be better as an LLDB command or breakpoint action?

The new SE-0088 types don't seem to have CustomStringConvertible or CustomDebugStringConvertible conformance.

-- Ben

···

On 19 Jun 2016, at 23:52, Jérôme Duquennoy via swift-evolution <swift-evolution@swift.org> wrote:

dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as I can see, and I can see uses in non-debugging contexts (logging is the obvious one) for knowing the current queue’s label (without also allowing the error-prone usage of dispatch_get_current_queue() itself). As such, I wouldn’t mind seeing this interface available on DispatchQueue, though I might name it simply "label", as in:

extension DispatchQueue {
  public class var label: String { get }
}

This would be in keeping with the way getSpecific() is named; IMO "DispatchQueue.label" is not ambiguous enough to require the extra "currentQueue" prefix. Or maybe "currentLabel", since if nothing else "queue" seems like noise to me, due to the repetition.

-- Gwynne Raskind

···

On Jun 20, 2016, at 04:02, Ben Rimmington via swift-evolution <swift-evolution@swift.org> wrote:

On 19 Jun 2016, at 23:52, Jérôme Duquennoy via swift-evolution <swift-evolution@swift.org> wrote:

With the release of swift 3, The interface to libDispatch has evolved quite a lot, to a much cleaner, object oriented interface.
There seems to be one feature that is no longer available :
In swift 2, it was possible to get the current queue label using "dispatch_queue_get_label(DISPATCH_CURRENT_QUEUE_LABEL)".

In the new interface, the DispatchQueue has a label property, but there seems to be no way to get the current queue.

Is that a design decision ?

[Cc: Matt Wright]

If not, a "current" class property should probably be added to "DispatchQueue".

`DispatchQueue.current` is unlikely to be accepted, because `dispatch_get_current_queue()` is deprecated (since iOS 6.0, macOS 10.9).

If yes, maybe we could add a "currentQueueLabel" class property to "DispatchQueue", but this doesn't look right to me : why should only this property of the current queue be available, and not other ones like "qos" ?

`DispatchQueue.currentQueueLabel` might be useful for debugging and logging. Or maybe this would be better as an LLDB command or breakpoint action?

The new SE-0088 types don't seem to have CustomStringConvertible or CustomDebugStringConvertible conformance.

-- Ben
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Chris Lattner: "Swift supports instance and type members with the same names, but this is controversial, leads to confusion, and may go away in the future."

<http://article.gmane.org/gmane.comp.lang.swift.evolution/14558/match=controversial+confusion+future&gt;

-- Ben

···

On 20 Jun 2016, at 10:14, Gwynne Raskind <gwynne@darkrainfall.org> wrote:

dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as I can see, and I can see uses in non-debugging contexts (logging is the obvious one) for knowing the current queue’s label (without also allowing the error-prone usage of dispatch_get_current_queue() itself). As such, I wouldn’t mind seeing this interface available on DispatchQueue, though I might name it simply "label", as in:

extension DispatchQueue {
  public class var label: String { get }
}

I stand corrected! "currentLabel" would be my prevailing suggestion, then.

-- Gwynne Raskind

···

On Jun 20, 2016, at 04:51, Ben Rimmington <me@benrimmington.com> wrote:

On 20 Jun 2016, at 10:14, Gwynne Raskind <gwynne@darkrainfall.org> wrote:

dispatch_queue_get_label() isn’t marked as a for-debugging-only API as far as I can see, and I can see uses in non-debugging contexts (logging is the obvious one) for knowing the current queue’s label (without also allowing the error-prone usage of dispatch_get_current_queue() itself). As such, I wouldn’t mind seeing this interface available on DispatchQueue, though I might name it simply "label", as in:

extension DispatchQueue {
  public class var label: String { get }
}

Chris Lattner: "Swift supports instance and type members with the same names, but this is controversial, leads to confusion, and may go away in the future."

<http://article.gmane.org/gmane.comp.lang.swift.evolution/14558/match=controversial+confusion+future&gt;

-- Ben