Fix deadlock with mappings for display controllers#15524
Conversation
|
Thanks for looking into this, I will test that ASAP |
| ConfigKey("[Controller]", sanitizeDeviceName(pController->getName())), 0); | ||
| } | ||
|
|
||
| // This needs to be called in a Qt::BlockingQueuedConnection so that the |
There was a problem hiding this comment.
is there any way to enforce that / check that at runtime?
There was a problem hiding this comment.
Could we not doing it by adding a thread affinity assertion?
There was a problem hiding this comment.
That would assert that it is not directly called from a different thread, not that the signalling thread is blocked.
daschuer
force-pushed
the
applyMappingFix
branch
from
7687503 to
d156e42
Compare
acolombier
left a comment
acolombier
left a comment
There was a problem hiding this comment.
Tested, and unfortunately, this doesn't fix the deadlock, and the main thread still lock due to the blocking connection.
Backtrace is the same.
|
Interesting. Can you post the backtrace? Which mapping do you use? |
|
I am using the mapping that it in |
daschuer
force-pushed
the
applyMappingFix
branch
from
d156e42 to
5c4a19d
Compare
|
Ah is see the Qt::QueuedConnection flag was lost. Now it should work. |
acolombier
left a comment
acolombier
left a comment
There was a problem hiding this comment.
Tested and works as expected! Let's merge and fix forward if anything doesn't work!
Thank you for taking care of that!
3 participants
This fixed the deadlock introduced via merging 2.5 to 2.6 that contains the incompatible "concurrent access crasher fix" #14159 and the "controller screen rendering" #11407
This the solution with the second slot called non blocking as discussed in #14606.