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?

vector<CService> vservNode(0);
            if(Lookup(strAddNode.c_str(), vservNode, Params().GetDefaultPort(), fNameLookup, 0))
            {
                lservAddressesToAdd.push_back(vservNode);
                {
                    LOCK(cs_setservAddNodeAddresses);
                    BOOST_FOREACH(const CService& serv, vservNode)
                        setservAddNodeAddresses.insert(serv);
                }
            }
        }
        
        
        {
            LOCK(cs_vNodes);
            BOOST_FOREACH(CNode* pnode, vNodes)
                for (list<vector<CService> >::iterator it = lservAddressesToAdd.begin(); it != lservAddressesToAdd.end(); it++)
                    BOOST_FOREACH(const CService& addrNode, *(it))
                        if (pnode->addr == addrNode)
                        {
                            it = lservAddressesToAdd.erase(it);
                            it--;
                            break;
                        }
        }
        BOOST_FOREACH(vector<CService>& vserv, lservAddressesToAdd)