Quando una goroutine blocca su I/O, in che modo lo scheduler identifica che ha smesso di bloccare?

Question

Da quello che ho letto here, lo scheduler golang determinerà automaticamente se una goroutine sta bloccando l'I/O e passerà automaticamente all'elaborazione di altre goroutine su un thread che non è bloccato.

Quello che mi chiedo è come lo scheduler capisca che quella goroutine ha smesso di bloccare l'I/O.

Fa semplicemente qualche tipo di polling ogni tanto per controllare se sta ancora bloccando? Esiste una sorta di thread in background in esecuzione che controlla lo stato di tutte le goroutine?

---

Per esempio, se si dovesse fare una richiesta HTTP GET all'interno di un goroutine che ha preso 5s per ottenere una risposta, avrebbe bloccato durante l'attesa per la risposta, e lo scheduler sarebbe passare ad un'altra elaborazione goroutine. Ora dato che, quando il server restituisce una risposta, in che modo lo scheduler capisce che la risposta è arrivata, ed è ora di tornare alla goroutine che ha fatto il GET in modo che possa elaborare il risultato del GET?

Answer 1

Tutti gli I/O devono essere eseguiti tramite le sysc e il modo in cui i sysc vengono implementati in Go, vengono sempre chiamati attraverso il codice controllato dal runtime. Ciò significa che quando chiamate un syscall, invece di chiamarlo direttamente (rinunciando quindi al controllo del thread sul kernel), il runtime viene avvisato del syscall che volete creare, e lo fa per conto della goroutine. Ciò consente, ad esempio, di eseguire un syscall non bloccante invece di uno bloccante (essenzialmente dicendo al kernel, "per favore fai questa cosa, ma invece di bloccare finché non è fatto, torna immediatamente, e fammi sapere più tardi una volta che il risultato è pronta"). Ciò gli consente di continuare a svolgere altri lavori nel frattempo.