Donc si je résume, ça plantait car la compilation de Rust fait beaucoup de thread qu'elle libère pour en recréer. En sois pour un programme moderne ça parait logique pour utiliser au maximum la parallélisation.
Mais surtout ce qui est intéressant c'est que d'un point de vue code, en sois, il n'y avait pas de Bug mais juste une limitation paramétrable à la compilation du noyau Haiku (qui avec son patch n'existera plus). Ca souligne un problème que j'ai maintes fois rencontré et qui bien souvent n'est pas si simple à résoudre : les problème de configuration. Parfois on est tenté de changer une variable pour juste que ça marche sans savoir si ça plante parce qu'on a un véritable Bug (souvent une fuite mémoire) ou si c'est normal car le programme n'a pas été prévu pour tourner dans les conditions extrême qu'on lui impose. Dans le cas de Haiku on peut dire que quelques part Haiku n'avait pas été conçut a l'époque pour avoir une aussi grosse utilisation de threads.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
Dans le cas de Haiku on peut dire que quelques part Haiku n'avait pas été conçut a l'époque pour avoir une aussi grosse utilisation de threads.
C'est pas gentil ça, pour un OS dont l'utilisation de très nombreux threads est le principal argument de vente :)
En fait cette limitation (arbitraire) concerne uniquement les threads "joinable", déjà terminés, et dont personne n'a encore récupéré le code de retour (via un pthread_join). Il y a une autre limite pour le nombre total de threads en cours d'exécution sur le système (pour l'instant, 4096 threads, ce qui n'a pas encore posé problème).
Le développeur qui a écrit ce code (et introduit cette limitation) ne participe plus à Haiku, on aura donc probablement jamais d'explications sur ce qu'il voulait faire. Je pense que son raisonnement était que les threads ne devraient normalement pas rester longtemps dans cet état. Le fonctionnement habituel est qu'on lance un ou plusieurs threads qui vont faire des traitements longs, puis on attend qu'ils se terminent. Cette liste est là pour le cas ou certains threads se termineraient avant qu'on aie commencé à les attendre.
Dans le cas de Rust, il semblerait que l'attente de la fin des threads ne survient que beaucoup plus tard et n'est même pas vraiment nécessaire (jusqu'à présent le problème avait été contourné en supprimant cette attente). C'est une façon différente, mais pas incorrecte, d'utiliser cette API.
La limitation du nombre de threads dans cet état est pertinente, parce qu'un programme qui fait "n'importe quoi" (de façon involontaire via un bug, ou volontaire pour essayer de faire planter le système) peut remplir cette liste sans limite, et finir par remplir l'espace mémoire du noyau. Mais la limite a été placée au mauvais endroit et ne permettait pas aux applications de traiter l'erreur.
La meilleure solution (sous-entendue dans la spécification POSIX, d'ailleurs) est de vérifier le nombre de threads dans cet état lors du pthread_create, et de refuser la création de nouveaux threads tant qu'il y en a trop. Cela permet de signaler l'erreur à l'application, et ensuite au développeur de la dite application de chercher le problème. C'est beaucoup mieux que de faire discrètement disparaître le cadavre d'un thread.
# De l'usage des paramètres
Posté par abriotde (site web personnel, Mastodon) . Évalué à 1. Dernière modification le 08 septembre 2020 à 04:47.
Donc si je résume, ça plantait car la compilation de Rust fait beaucoup de thread qu'elle libère pour en recréer. En sois pour un programme moderne ça parait logique pour utiliser au maximum la parallélisation.
Mais surtout ce qui est intéressant c'est que d'un point de vue code, en sois, il n'y avait pas de Bug mais juste une limitation paramétrable à la compilation du noyau Haiku (qui avec son patch n'existera plus). Ca souligne un problème que j'ai maintes fois rencontré et qui bien souvent n'est pas si simple à résoudre : les problème de configuration. Parfois on est tenté de changer une variable pour juste que ça marche sans savoir si ça plante parce qu'on a un véritable Bug (souvent une fuite mémoire) ou si c'est normal car le programme n'a pas été prévu pour tourner dans les conditions extrême qu'on lui impose. Dans le cas de Haiku on peut dire que quelques part Haiku n'avait pas été conçut a l'époque pour avoir une aussi grosse utilisation de threads.
Sous licence Creative common. Lisez, copiez, modifiez faites en ce que vous voulez.
[^] # Re: De l'usage des paramètres
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 6.
C'est pas gentil ça, pour un OS dont l'utilisation de très nombreux threads est le principal argument de vente :)
En fait cette limitation (arbitraire) concerne uniquement les threads "joinable", déjà terminés, et dont personne n'a encore récupéré le code de retour (via un pthread_join). Il y a une autre limite pour le nombre total de threads en cours d'exécution sur le système (pour l'instant, 4096 threads, ce qui n'a pas encore posé problème).
Le développeur qui a écrit ce code (et introduit cette limitation) ne participe plus à Haiku, on aura donc probablement jamais d'explications sur ce qu'il voulait faire. Je pense que son raisonnement était que les threads ne devraient normalement pas rester longtemps dans cet état. Le fonctionnement habituel est qu'on lance un ou plusieurs threads qui vont faire des traitements longs, puis on attend qu'ils se terminent. Cette liste est là pour le cas ou certains threads se termineraient avant qu'on aie commencé à les attendre.
Dans le cas de Rust, il semblerait que l'attente de la fin des threads ne survient que beaucoup plus tard et n'est même pas vraiment nécessaire (jusqu'à présent le problème avait été contourné en supprimant cette attente). C'est une façon différente, mais pas incorrecte, d'utiliser cette API.
La limitation du nombre de threads dans cet état est pertinente, parce qu'un programme qui fait "n'importe quoi" (de façon involontaire via un bug, ou volontaire pour essayer de faire planter le système) peut remplir cette liste sans limite, et finir par remplir l'espace mémoire du noyau. Mais la limite a été placée au mauvais endroit et ne permettait pas aux applications de traiter l'erreur.
La meilleure solution (sous-entendue dans la spécification POSIX, d'ailleurs) est de vérifier le nombre de threads dans cet état lors du pthread_create, et de refuser la création de nouveaux threads tant qu'il y en a trop. Cela permet de signaler l'erreur à l'application, et ensuite au développeur de la dite application de chercher le problème. C'est beaucoup mieux que de faire discrètement disparaître le cadavre d'un thread.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.