Priority inversion? #8010

During some lock debugging on a dual-core Linux system I noticed that threads are blocked acquiring cs_vNodes and cs_main for long periods when the system is under moderate load from unrelated processes -- the unlucky lock acquirer is waiting for single-digit seconds once every 10 minutes or so (not coinciding with new blocks) up to around a 30 second wait every few hours. It looks like ThreadMessageHandler is taking locks and then due to being set to THREAD_PRIORITY_BELOW_NORMAL, it's being descheduled (even in trivial lock-holding regions like GetHeight) and holding up for arbitrarily long periods other threads that use these core locks.

So I'm wondering, what are the benefits of running the message handler at low priority?

I wasn't aware that the message processing thread is run with lower priority. To me that makes little sense, as part of the validation work (or all validation work, in the case of -par=1) is done there.

I'd be for removing SetThreadPriority functionality completely - it used to be used for the miner threads, but that has been removed, now the only call is for the message thread. And as you say that has doubtful utility...

Looks like this priority change always been there, from the first commit in git at least.

Cannot find any prior discussion about it, anywhere.

Good catch.