Pourquoi un Goroutine à boucle infinie bloque-t-il un serveur HTTP Go malgré des ressources suffisantes ?

Goroutine à boucle infinie bloque le serveur HTTP Go

Le runtime Go, responsable de la gestion de l'exécution simultanée, est fier de ses opérations non bloquantes. Cependant, un scénario impliquant une goroutine en boucle infinie initiée depuis un serveur HTTP soulève une préoccupation. Malgré le nombre suffisant de threads et de goroutines (selon runtime.GOMAXPROCS), cette boucle infinie semble bloquer le traitement des autres requêtes par le serveur.

Pour illustrer le problème, vous avez fourni un exemple de code présentant un serveur avec une -loop goroutine (désactivé par défaut) et un client envoyant des requêtes HTTP simultanées. Avec la goroutine désactivée, le client affiche l'ensemble d'astérisques attendu. Cependant, son activation entraîne un blocage de la sortie du client après une poignée de requêtes.

Le mystère persiste même après avoir expérimenté le runtime.LockOSThread au sein de la goroutine, car il ne parvient pas à résoudre le blocage. Selon la documentation de Go, runtime.LockOSThread devrait exécuter la boucle infinie dans un thread séparé, sans affecter les autres goroutines.

Ce comportement déroutant pourrait être attribué au planificateur d'exécution de Go. Bien que préventif dans une certaine mesure, ce n’est pas entièrement le cas. Go 1.2 a introduit des améliorations en forçant des invocations occasionnelles du planificateur lors des appels de fonction. Cependant, les boucles infinies de cet exemple manquent d'appels de fonction, contournant cette solution.

Envisagez d'ajouter un travail significatif à vos gestionnaires de boucles infinies. Alternativement, un appel délibéré à runtime.Gosched pourrait atténuer le problème de blocage.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!