thread di lavoro di libuv o controllo dello stato della coda di lavoro?

Question

In libuv, si può finire per legare i thread di lavoro con troppo lavoro o codice bug. Esiste una semplice funzione in grado di verificare lo stato dei thread worker o della coda thread? Non deve essere deterministico al 100%, dopotutto sarebbe impossibile determinare se il thread worker è sospeso su un codice lento o su un loop infinito.

Così uno dei seguenti euristica sarebbe buono:

• Numero di elementi in coda non ancora lavorato. Se questo è troppo grande, potrebbe significare che i thread di lavoro sono occupati o bloccati.

• La libreria di libuv presenta un meccanismo di eliminazione dei thread in cui, se il thread di lavoro non esegue il checkback in secondi, viene terminato?

Answer 1

Tale funzione non esiste in libuv sé, e io non sono a conoscenza di alcun OSS che fornisce qualcosa di simile.

In termini di un meccanismo di uccisione, non c'è nessuno cotto in libuv, ma http://nikhilm.github.io/uvbook/threads.html#core-thread-operations suggerisce:

Un programma ben progettato dovrebbe avere un modo per porre fine a lungo in esecuzione lavoratori che hanno già iniziato l'esecuzione. Un tale operatore può controllare periodicamente per una variabile che solo il processo principale imposta sulla terminazione del segnale .

Answer 2

Se questo è per nodejs, farebbe un semplice thread di monitoraggio? Non conosco un modo per ottenere informazioni sugli interni delle code degli eventi, ma è possibile iniettare un tracciante nella coda degli eventi per monitorare i thread in corso in modo tempestivo. (Questo misura il carico non dal numero di thread non ancora eseguiti, ma dal fatto che i thread vengano eseguiti in tempo.)

Un thread del monitor può ri-fare la coda e controllare che venga chiamato almeno ogni 10 millisecondi (o qualunque sia il massimo cumulativo di ms di blocco consentito). Poiché nodej esegue i thread round-robin, se il thread del monitor è stato eseguito in tempo, ci dice che tutti gli altri thread hanno la possibilità di essere eseguiti all'interno della stessa finestra di 10 ms. Qualcosa di simile (in nodi):

// 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(); 

Throttling i messaggi di avviso e sostenere una chiusura pulita è un esercizio lasciato al lettore.