I see this warning when my app runs:
Thread running at QOS_CLASS_USER_INTERACTIVE waiting on a lower QoS thread running at QOS_CLASS_DEFAULT. Investigate ways to avoid priority inversions
This is true; I know what is going on. I'd like this other thread to have a higher priority. But how do I set the "QOS class" for a thread?
Searching developer.apple.com for QOS_CLASS_USER_INTERACTIVE doesn't find much. It seems that dispatch queues have priorities, but in this case I have a thread, not a dispatch queue.
Any ideas?
Below is some simple code that does nothing, saves nothing. Yet the memory usage keeps rising. Am I missing something or is this a bug?
The code requires 6 core CPU minimum.
ContentView.swift
import SwiftUI
import Combine
struct ContentView: View {
@EnvironmentObject var loopClass:LoopClass
var body: some View {
ProgressView(value: Float(loopClass.loop_count), total: Float(loopClass.max_loops) ).progressViewStyle(.circular).padding()
Button("Run looper", action: {
loopClass.loopFunc()
}
)
}
}
LoopClass.swift
import Combine
class LoopClass: ObservableObject {
@Published var loop_count = 0
@Published var max_loops = 0
func loopFunc () {
let loopSet = [ 1, 3, 5, 7, 11, 13 ]
max_loops = Int(pow(Double(loopSet.count), 13.0))
print("max_loops = \(max_loops)")
for loop13 in loopSet {
DispatchQueue.global().async {
for loop12 in loopSet {
for loop11 in loopSet {
for loop10 in loopSet {
for loop9 in loopSet {
for loop8 in loopSet {
for loop17 in loopSet {
for loop16 in loopSet {
for loop5 in loopSet {
for loop4 in loopSet {
for loop3 in loopSet {
for loop2 in loopSet {
for loop1 in loopSet {
DispatchQueue.main.async{ self.loop_count += 1 }
}
}}}}}}}}}}}
} // DQ
} // for loop13
}
}
Post not yet marked as solved
Looks like dispatch has been broken
Post not yet marked as solved
In What's New In Swift, a new DispatchSerialQueue-backed actor was introduced. We're able to call MainActor-annotated functions using DispatchQueue.main.async without errors or warnings. For example:
@MainActor
func randomFunc() {
print("Hello World")
}
DispatchQueue.main.async {
randomFunc()
}
However calling a globalActor-annotated function or a regular actor-isolated function backed by a DispatchSerialQueue, we get the warning Actor-isolated instance method 'randomFunc()' can not be referenced from a non-isolated context; this is an error in Swift 6. Code here:
actor MyActor {
private let queue: DispatchSerialQueue
nonisolated var unownedExecutor: UnownedSerialExecutor { queue.asUnownedSerialExecutor() }
init(queue: DispatchSerialQueue) {
self.queue = queue
}
func randomFunc() {
print("Hello World!")
}
}
let queue = DispatchSerialQueue(label: "actorQueue")
let actor = MyActor(queue: queue)
queue.async {
actor.randomFunc() // Warning here
}
Although it has a warning, the code still runs successfully and prints Hello World, but it would also do so from another DispatchQueue not used by the actor (this was tested in Version 15.0 beta (15A5160n) Playground).
My question: Can we remove the warning resulting from calling an actor isolated function backed by DispatchSerialQueue A using A.async { }, if that's safe behavior? If it's not safe, why not?
Do run loops use an operation queue under the hood?
When I dispatch to the mian queue, I know it will run on the mian thread, which means it will be handled b the main thread's run loop. But is the other way around correct?
More specific question, is it possible somehow that the following code will return true?
OperationQueue.current != OperationQueue.main && Thread.isMainThread
I tried to do for example to dispatch to the main thread using a timer.
myQueue.sync {
let timer = Timer(timeInterval: 1, repeats: false) { _ in
let curr = OperationQueue.current
let main = OperationQueue.main
print("\(String(describing: curr)) \(main)")
}
RunLoop.main.add(timer, forMode: .common)
}
And got the same pointer. But maybe some other way of dispatching to the main run loop will give different results, possibly that is why OperationQueue.current can return nil.
Post not yet marked as solved
Experiencing an increased amount of crash reports with the latest release of the app. I've spent some time online understanding the meaning of Unbalanced call to dispatch_group_leave() however, I am struggling to pinpoint what's the source of the problem inside the codebase. I wish you can help me with these crash logs.
Will calling a closure from inside CoreData context's perform() will eventually result into this crash and cause leave() to get called multiple times? The main code was there for long time, the only recent change was to wrap some code around CoreData context perform() or performAndWait() to avoid concurrency issues.
2023-05-20_10-42-03.5467_+0100-e8b3d9b142b8fd3d11c72abc01ad2fbcfbe92aee.crash
2023-05-22_20-57-32.2620_+0400-5d4c76afe1e42937cf09035d3034fb33ec40f0c9.crash
2023-05-21_19-36-18.3480_+0100-c01f62a2b78cae616c6202940f06220b7ea3b760.crash
2023-05-16_15-29-43.3962_+0100-ebb44a6156a3771271acfdd459546fe1271eb370.crash
I'm running a simulation (SwiftUI app), which has 100 steps.
I need each step to be executed in order.
A first try was to dispatch with delay to schedule each second:
for step in 0..<100 {
DispatchQueue.main.asyncAfter(deadline: .now() + Double(step) * 1.0) {
// simulation code
}
}
Very poor results as 100 running threads are too much load for the system.
So I split in 2 stages:
for bigStep in 0..<10 {
DispatchQueue.main.asyncAfter(deadline: .now() + Double(bigStep) * 10.0 ) {
for step in 0..<10 {
DispatchQueue.main.asyncAfter(deadline: .now() + Double(step) * 1.0) {
// simulation code
}
}
}
}
It works much better, as now there are a max of 20 threads active (in fact I create more levels to limit to a max of 8 concurrent threads).
It addition, it allows to interrupt the simulation before end.
My questions:
is it the appropriate pattern ?
Would a timer be better ?
Other options ?
Post not yet marked as solved
I understand UI updates have to be on the main thread, but what about SKSpriteNode's texture? Can I update that in the background?
I can update it in the background and it works like I want it to. No crashes, warnings, etc. I did verify that the thread is not the main thread via [NSThread isMainThread].
I have since wrapped the texture change in a dispatch_sync on the main queue and it works the same as without it.
Regards, Patrick
Post not yet marked as solved
I'm using JSONDecoder().decode(T.Type, from: data) to decode a JSON response from a server. It works in some cases but eventually my program crashes with the error "Stack buffer overflow".
The size of the JSON data I'm trying to decide is about 16k, which is large, but not unusually so.
The decode is happening in a non-main thread, but I tried pushing it into the main thread with the same results.
Most of these crashes occur in the simulator rather than on a real device, but I'd like to figure out the problem anyway.
I thought I'd try dispatching the work into a queue with a larger stack size, but I couldn't figure out how to make one. Is it possible?
Thanks,
Frank
Post not yet marked as solved
has anyone else noticed much slower GCD runs in newer MacOS / Catalyst
this seems like it used to be blazing fast:
dispatch_async(dispatch_get_global_queue(QOS_CLASS_USER_INTERACTIVE, 0), ^{
// code to run
});
now if I run a block on this type of queue versus the main thread, the dispatched code runs much slower vs main thread. not 10%, like multiple slower. i am not sure yet if it is the code run time or time for dispatch to trigger. trying to focus in on what is the problem on our side and get some metrics, but if anyone has seen this issue, it might be useful to compare notes.
Since updating to iOS 16.4.1, our app crashes randomly with the following error message.
Exception Codes: 0x0000000000000001, 0x0000000199d542c0
Termination Reason: SIGNAL 5 Trace/BPT trap: 5
Terminating Process: exc handler [499]
Triggered by Thread: 2
Thread 2 Crashed:
0 libdispatch.dylib 0x199d542c0 _dispatch_assert_queue_fail + 120
1 libdispatch.dylib 0x199d54248 dispatch_assert_queue + 196
2 UIKitCore 0x1949c870c -[UIImageView _mainQ_beginLoadingIfApplicable] + 88
3 UIKitCore 0x19495db34 -[UIImageView setHidden:] + 68
4 UIKitCore 0x19492f128 -[UIButtonLegacyVisualProvider _updateImageView] + 372
5 UIKitCore 0x19492ed78 -[UIButtonLegacyVisualProvider layoutSubviews] + 116
6 UIKitCore 0x19492ecc4 -[UIButton layoutSubviews] + 40
7 UIKitCore 0x1948fbef4 -[UIView(CALayerDelegate) layoutSublayersOfLayer:] + 1920
8 QuartzCore 0x193db64ac CA::Layer::layout_if_needed(CA::Transaction*) + 500
9 QuartzCore 0x193dc9a28 CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 148
10 QuartzCore 0x193ddae54 CA::Context::commit_transaction(CA::Transaction*, double, double*) + 444
11 QuartzCore 0x193e0a3c0 CA::Transaction::commit() + 648
12 QuartzCore 0x193e54b08 CA::Transaction::release_thread(void*) + 228
13 libsystem_pthread.dylib 0x1f2214b9c _pthread_tsd_cleanup + 620
14 libsystem_pthread.dylib 0x1f2217560 _pthread_exit + 84
15 libsystem_pthread.dylib 0x1f22140cc _pthread_wqthread_exit + 80
16 libsystem_pthread.dylib 0x1f2213e64 _pthread_wqthread + 424
17 libsystem_pthread.dylib 0x1f2213b7c start_wqthread + 8
I have trouble interpreting where our error lies within the exception.
Can anyone give me a hint as to what kind of problem this might be?
Kind regards
endecotp.
