AutoreleaseFrequency on DispatchQueue in Swift 3 Beta 5

Question

In Xcode 8 Beta 5 wurde der Initialisierer für DispatchQueue geändert, um separate Argumente für Qos (Quality of Service), Attribute und Autorelease-Häufigkeit zu akzeptieren. Obwohl ich keine Probleme hatte, meinen Code in den neuen Initialisierer zu konvertieren, bin ich unsicher bezüglich der Bedeutung einiger Attribute, insbesondere der Autorelease-Häufigkeit.

Zum Beispiel in Xcode 8 Beta 3 und Swift 3, konnte ich eine serielle DispatchQueue als solche erstellen:

let serialQueue = DispatchQueue(label: "Concurrent Map", attributes: [.serial, .qosBackground], target: nil) 

In Xcode 8 Beta 5 und Swift 3:

let serialQueue = DispatchQueue(label: "Concurrent Map", qos: .background, attributes: [], autoreleaseFrequency: .inherit, target: nil) 

Meine Fragen sind:

• In der neuen DispatchQueue.Attributes, .serial ist nicht länger ein Mitglied. Bedeutet dies, dass das Fehlen von .concurrent eine serielle Warteschlange erstellt. Ein erster Test, den ich in Swift Playgrounds gemacht habe, scheint dies zu bestätigen. Kann jemand anderes bestätigen?
• Ich sehe, dass DispatchQueue.AutoreleaseFrequency ist ein neuer Typ mit .inherit, .Never und .WorkItem. Was bedeuten diese? Ich habe etwas über GCD und Autoreleasing geforscht, aber ich bin nicht sehr vertraut mit dem Konzept der Autorelease-Pools.

Answer 1

Ich konnte keine offizielle Dokumentation dieser neuen Attribute finden (es ist wahrscheinlich gearbeitet wird), aber die vorhandene GCD Dokumentation gegeben, und zwischen den Zeilen lesen, ist es ziemlich einfach, intuitiv zu erfassen, was hier gemeint ist.

In den neuen DispatchQueue.Attributes ist .serial kein Mitglied mehr. Bedeutet dies, dass das Fehlen von .concurrent eine serielle Warteschlange erstellt. Ein erster Test, den ich in Swift Playgrounds gemacht habe, scheint dies zu bestätigen. Kann jemand anderes bestätigen?

Ja. Eine Warteschlange ist entweder seriell oder gleichzeitig. Die meisten Warteschlangen, die Sie erstellen, sind seriell, Sie müssen sie also nur als gleichlaufend festlegen, wenn Sie das Standardverhalten nicht möchten.

Ich sehe, dass DispatchQueue.AutoreleaseFrequency ist ein neuer Typ mit .inherit, .never und .workItem. Was bedeuten diese? Ich habe einige Forschung über GCD und Autoreleasing, aber ich bin nicht sehr vertraut mit dem Konzept der Autorelease-Pools.

Früher wurden DispatchQueues ihre Autorelease-Pools zu nicht angegebenen Zeiten (wenn der Thread inaktiv wurde). In der Praxis bedeutet dies, dass Sie entweder für jedes von Ihnen übermittelte Versandelement einen Autorelease-Pool erstellt haben oder dass Ihre automatisch freigegebenen Objekte für eine unvorhersehbare Zeit blockiert sind.

Nicht-Determinismus ist keine große Sache (vor allem in einer Gleichzeitigkeit Bibliothek!) Zu haben, so dass sie können Sie jetzt eine von drei Verhaltensweisen spezifizieren:

.inherit: Nicht sicher, wahrscheinlich die vorher-default Verhalten

.workItem: erstellen und einen Autofreigabepool für jedes Element Drain, die

ausgeführt wird.Niemals: GCD verwaltet keine Autorelease-Pools für Sie

Aus all diesen Gründen werden Sie wahrscheinlich nur .WorkItem verwenden, da es Ihre temporären Objekte bereinigt, wenn das Objekt fertig ist. Die anderen Optionen sind vermutlich für Buggy-Code, der von dem alten Verhalten abhängt, oder für den seltenen Benutzer, der dieses Zeug selbst verwalten möchte.

---

Eigentlich dachte, es geht um ein bisschen mehr, wenn Sie Workitems sind einreichen, die Swift-only sind (sie nennen nicht in jedem Objective-C-Code), dann ist .never wahrscheinlich sicher & korrekt . Angesichts der Tatsache, dass einige/alle Swift-Standardbibliotheksklassen einen Objective-C-Code aufrufen, möchten Sie dies wahrscheinlich auf Berechnungen beschränken, die vollständig in Ihrem eigenen Swift-Code enthalten sind.

Answer 2

Ich finde die Antwort von Mark "subjektiv", wie er sagte, keine offizielle Dokumentation ist in den Dokumenten noch heraus. Sie können jedoch offizielle Dokumentation im Code finden, also gebe ich, was ich glaube, sollte die richtige Antwort sein, da es rein auf dem basiert, was in der Code-Dokumentation und nicht in der Meinung gefunden wird. Hier ist sie:

DISPATCH_AUTORELEASE_FREQUENCY_INHERIT Dispatch-Warteschlangen mit dieser Autorelease Frequenz das Verhalten von ihrer Zielwarteschlange erben. Dies ist das Standardverhalten für manuell erstellte Warteschlangen.

DISPATCH_AUTORELEASE_FREQUENCY_WORK_ITEM Dispatch-Warteschlangen mit diesem Autorelease Frequenz Push- und Pop einen Autofreigabepool um die Ausführung eines jeden Block, der ihm asynchron vorgelegt wurde.

DISPATCH_AUTORELEASE_FREQUENCY_NEVER Dispatch-Warteschlangen mit diesem Autorelease Frequenz nie ein individuelles Autofreigabepool um die Ausführung eines Blocks eingerichtet, die asynchron zu ihm vorgelegt wird. Dies ist das Verhalten der globalen gleichzeitigen Warteschlangen.