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?

{
public:
    
    boost::signals2::signal<std::string (const char* psz)> Translate;
};
extern std::map<std::string, std::string> mapArgs;
extern std::map<std::string, std::vector<std::string> > mapMultiArgs;
extern bool fDebug;
extern bool fPrintToConsole;
extern bool fPrintToDebugLog;
extern bool fServer;
extern std::string strMiscWarning;
extern bool fLogTimestamps;
extern bool fLogTimeMicros;
extern bool fLogIPs;
extern volatile bool fReopenDebugLog;
extern CTranslationInterface translationInterface;
extern const char * const BITCOIN_CONF_FILENAME;
extern const char * const BITCOIN_PID_FILENAME;
/**
 * Translation function: Call Translate signal on UI interface, which returns a boost::optional result.
 * If no translation slot is registered, nothing is returned, and simply return the input.
 */
inline std::string _(const char* psz)