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?

#define S_IRUSR             0400
#define S_IWUSR             0200
#endif
#else
#define MAX_PATH            1024
#endif
#if !defined(HAVE_MSG_NOSIGNAL) && !defined(MSG_NOSIGNAL)
#define MSG_NOSIGNAL 0
#endif
#ifndef WIN32
#ifndef PRIO_MAX
#define PRIO_MAX 20
#endif
#define THREAD_PRIORITY_LOWEST          PRIO_MAX
#define THREAD_PRIORITY_BELOW_NORMAL    2
#define THREAD_PRIORITY_NORMAL          0
#define THREAD_PRIORITY_ABOVE_NORMAL    (-2)
#endif
#if HAVE_DECL_STRNLEN == 0
size_t strnlen( const char *start, size_t max_len);
#endif 
bool static inline IsSelectableSocket(SOCKET s) {
#ifdef WIN32
    return true;
#else
    return (s < FD_SETSIZE);
#endif
}
#endif