Qu'est-il arrivé à libgreen?
Pour autant que je comprends libgreen ne fait plus partie de Rust bibliothèque standard plus. Je ne trouve pas non plus de paquet libgreen séparé. Il y a quelques alternatives - - coroutine , qui ne fournit pas de threads verts réels pour l'instant, et green-rs , qui est cassé. Est-ce que je comprends bien que pour l'instant il n'y a pas de processus Go-like légers dans Rouille?
Vous avez raison, il n'y a pas de bibliothèque de tâches légère dans std (ou le reste de la distribution principale), que green ne compile pas et que coroutine ne semble pas gérer pleinement l'aspect de filetage encore. Je ne connais aucune autre bibliothèque dans cet espace.
Quant à ce qui s'est passé: le RFC lié à ce problème — RFC 2 - est la source canonique d'informations. Le résumé est qu'il a été constaté que la méthode par laquelle le filetage vert/E/S était géré (std a essayé d'abstraire sur les deux modèles, leur permettant d'être utilisés de manière interopérable de manière automatisée) ne valait pas les inconvénients. Maintenant, std vise simplement à fournir une ligne de base minimale de support utile: pour IO/threading, cela signifie "mince", des wrappers sûrs pour la fonctionnalité du système d'exploitation.
Lisez ceci https://aturon.github.io/blog/2016/08/11/futures/ et aussi:
réponse de Steve Klabnik dans les commentaires:
Au début, Rust n'avait que des threads verts. Finalement, il a été décidé qu'un langage système sans threads système est ... étrange. Nous avons donc dû les ajouter. Pourquoi ne pas ajouter de choix? Puisque les interfaces pourraient être les mêmes, pourquoi ne pas les résumer, et vous pourriez simplement choisir celle que vous vouliez?
Dans le même temps, les problèmes avec les threads verts par défaut devenaient des problèmes. Les piles segmentées provoquent une interopérabilité lente en C. Vous avez besoin d'un runtime pour les gérer, etc. De plus, l'abstraction globale entraînait un coût inacceptable. Les fils verts n'étaient pas très verts. De plus, avec la nécessité de publier un jour ou l'autre, des décisions devaient être prises concernant les compromis. Et puisque Rust est censé être un langage système, ayant des threads 1: 1 et essentiellement aucun runtime n'a plus de sens que les threads N: M et un runtime. Donc libgreen a été supprimé, l'interface a été refait pour être centré sur le filetage 1: 1.
La "sortie un jour imminente" en est une grande partie. Nous voulons être vraiment stables avec Rust, et avec toutes les choses à faire pour expédier un 1.0, nous ne voulions pas cristalliser une interface dont nous n'étions pas satisfaits. Heck, nous avons sorti beaucoup de bibliothèques qui sont encore moins importantes pour des raisons similaires, comme Rand. L'ingénierie est une question de compromis et nous avons décidé de choisir le minimalisme.
mio n'est pas un démarreur pour nous, comme la plupart des autres frameworks d'E/S asynchrones pour Rust, car nous avons besoin de Windows et en plus nous ne voulons pas être enfermés dans une bibliothèque coûteuse à remplacer qui pourrait devenir orpheline.
Entièrement compris ici, surtout dans le cas général. Dans le cas spécifique, mio aura soit la prise en charge de Windows, soit une version spécifique à Windows de mio sera publiée, avec un package de niveau supérieur fournissant les fonctionnalités pour toutes les plates-formes. Et dans ce cas, il est maintenu par l'une des personnes qui utilise actuellement Rust fortement en production, il est donc peu probable qu'il disparaisse de sitôt. Mais, à moins que vous ne soyez activement impliqué, il est difficile de savoir des choses comme ça, qui est, en soi, un problème.
L'une des raisons pour lesquelles nous étions à l'aise de supprimer libgreen est que vous pouvez écrire vos propres bibliothèques pour effectuer différents types d'E/S. 1.0 est un noyau solide que nous nous sentons bien de stabiliser pour toujours, pas le dernier morceau. Des bibliothèques comme https://github.com/carllerche/mio peuvent tester différentes façons de gérer des choses comme async IO, et, lorsqu'elles sont suffisamment matures, nous pouvons toujours les retirer dans la norme bibliothèque si besoin est. Mais en attendant, ce n'est qu'une ligne vers votre Cargo.toml pour les ajouter.
Et tel texte de reddit :
Malheureusement, ils ont fini par conserver le support de greenlet parce que le leur était plus lent que les threads du noyau, ce qui démontre à son tour que quelqu'un ne comprenait pas comment obtenir un compilateur de langage pour générer efficacement des coroutines sans pile (pas surprenant, le nombre d'ingénieurs câblés de la bonne façon n'est pas beaucoup dans ce monde, mais voir http://www.reddit.com/r/Rust/comments/2l0a4b/do_Rust_web_servers_use_libuv_through_libgreen_or/ pour plus de détails). Et ils ont mis en conserve les E/S asynchrones parce que libuv est "lent" (ce qui est uniquement dû au fait qu'il est à un seul thread, plus force un malloc + gratuit par opération asynchrone car les tampons doivent durer jusqu'à la fin de l'achèvement, plus il impose une pénalité sur E/S synchrones voir http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html ), ce qui était vraiment dommage - ils aurait dû saisir l'occasion de remplacer libuv par quelque chose de mieux (indice: ASIO + AFIO, et oui je sais qu'ils sont tous les deux en C++, mais Rust pourrait faire avec une bien meilleure interopérabilité en C++ que pour le moment aucun) a actuellement) au lieu de conserver toujours-async-tout dans ce qui aurait pu être une étape étonnante par rapport à C++ avec la plupart des avantages d'Erlang sans les inconvénients d'Erlang.
Pour les nouveaux arrivants, il existe désormais may , une caisse qui implémente des fils verts similaires aux goroutines.