Рабочие потоки libuv или проверка работоспособности очереди?

Question

В libuv вы можете связать рабочие потоки с слишком большим количеством работы или ошибкой кода. Есть ли простая функция, которая может проверять работоспособность рабочих потоков или очереди потоков? Он не должен быть 100% детерминированным, ведь было бы невозможно определить, висит ли рабочий поток на медленном коде или бесконечном цикле.

Таким образом, любой из следующих эвристических было бы хорошо:

• Количество элементов в очереди еще не работал. Если это слишком велико, это может означать, что рабочие потоки заняты или висели.

• Имеет ли libuv какой-либо механизм уничтожения нити, если рабочий поток не проверяет через n секунд, он заканчивается?

Answer 1

Эта функция не существует в самом libuv, и я не знаю ни одного OSS, который предоставляет что-то подобное.

С точки зрения механизма убийства, нет ни запеченные в libuv, но http://nikhilm.github.io/uvbook/threads.html#core-thread-operations предлагает:

Хорошо разработанная программа будет иметь возможность прекратить длительные работников, которые уже приступили к выполнению. Такой работник мог периодически проверять переменную, что только основной процесс устанавливает на завершение сигнала.

Answer 2

Если это для nodejs, будет ли простая нить монитора? Я не знаю, как получить информацию о внутренностях очереди событий, но вы можете ввести трассировщик в очередь событий, чтобы контролировать, что потоки выполняются своевременно. (Это измеряет нагрузку не на количество потоков, которые еще не запущены, а на то, что потоки запускаются вовремя. То же самое, вид.)

Мониторная нить может переупорядочивать сама и проверять, что она вызвана по крайней мере каждые 10 миллисекунд (или любой возможный максимальный кумулятивный запрет ms). Поскольку nodej запускает потоки round-robin, если поток монитора был запущен вовремя, он сообщает нам, что все остальные потоки получили возможность запускать в этом же окне 10 мс. Нечто подобное (в узле):

// like Date.now(), but with higher precision 
// the extra precision is needed to be able to track small delays 
function dateNow() { 
    var t = process.hrtime(); 
    return (t[0] + t[1] * 1e-9) * 1000; 
} 

var _lastTimestamp = dateNow(); // when healthMonitor ran last, in ms 
var _maxAllowedDelay = 10.0;  // max ms delay we allow for our task to run 
function healthMonitor() { 
    var now = dateNow(); 
    var delay = now - _lastTimestamp; 
    if (delaly > _maxAllowedDelay) { 
     console.log("healthMonitor was late:", delay, " > ", _maxAllowedDelay); 
    } 
    _lastTimestamp = now; 
    setTimeout(healthMonitor, 1); 
} 

// launch the health monitor and run it forever 
// note: the node process will never exit, it will have to be killed 
healthMonitor(); 

Троттлинг предупреждающих сообщений и поддерживать чистую остановку упражнения читателя.