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?

fstore_t fst;
    fst.fst_flags = F_ALLOCATECONTIG;
    fst.fst_posmode = F_PEOFPOSMODE;
    fst.fst_offset = 0;
    fst.fst_length = (off_t)offset + length;
    fst.fst_bytesalloc = 0;
    if (fcntl(fileno(file), F_PREALLOCATE, &fst) == -1) {
        fst.fst_flags = F_ALLOCATEALL;
        fcntl(fileno(file), F_PREALLOCATE, &fst);
    }
    ftruncate(fileno(file), fst.fst_length);
#elif defined(__linux__)
    
    off_t nEndPos = (off_t)offset + length;
    posix_fallocate(fileno(file), 0, nEndPos);
#else
    
    
    static const char buf[65536] = {};
    fseek(file, offset, SEEK_SET);
    while (length > 0) {
        unsigned int now = 65536;
        if (length < now)
            now = length;
        fwrite(buf, 1, now, file); 
        length -= now;
    }
#endif
}
void ShrinkDebugFile()