How to avoid this thread priority inversions ?

Context: Xcode 16.4, Appkit

In a windowController, I need to create and send a mouseDown event (newMouseDownEvent).

I create the event with:

let newMouseDownEvent = NSEvent.mouseEvent(
       with: .leftMouseDown,
       location: clickPoint,
       // all other fields

I also need to make window key and front, otherwise the event is not handled.  

 func simulateMouseDown() {
    self.window?.makeFirstResponder(self.window)   
    self.calepinFullView.perform(#selector(NSResponder.self.mouseDown(with:)), with: newMouseDownEvent!) 
}

 

As I have to delay the call( 0.5 s), I use asyncAfter:

        DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, qos: .userInteractive) {  
            self.simulateMouseDown()   
        }

 

It works as intended, but that generates the following (purple) warning at runtime:

[Internal] Thread running at User-interactive quality-of-service class waiting on a lower QoS thread running at Default quality-of-service class. Investigate ways to avoid priority inversions

I have tried several solutions,

  • change qos in await:
DispatchQueue.main.asyncAfter(deadline: .now() + 0.5, qos: ..default)
  • call from a DispatchQueue
            let interactiveQueue = DispatchQueue.global(qos: .userInteractive)
            interactiveQueue.async {
                self.window?.makeFirstResponder(self.window)
                self.calepinFullView.perform(#selector(NSResponder.self.mouseDown(with:)), with: newMouseDownEvent!) 
            }

But that's worse, it crashes with the following error:

FAULT: NSInternalInconsistencyException: -[HIRunLoopSemaphore wait:] has been invoked on a secondary thread; the problem is likely in a much shallower frame in the backtrace; {
    NSAssertFile = "HIRunLoop.mm";
    NSAssertLine = 709;
}

 

How to eliminate the priority inversion risk (not just silencing the warning) ?

Answered by Claude31 in 876710022

Thanks for the advice. But I can't reproduce the warning anymore.

Hi, the runtime warnings are accompanied by a backtrace associated with the warning in the Issue Navigator. Can you uncollopase the chevron in the Issue Navigator and share the backtrace so that we can see which framework is the warning originating from ?

Accepted Answer

Thanks for the advice. But I can't reproduce the warning anymore.

How to avoid this thread priority inversions ?
 
 
Q