rust - ¿Qué le pasó a libgreen?
coroutine (3)
Según tengo entendido, libgreen ya no forma parte de la biblioteca estándar de Rust . También no puedo encontrar un paquete libgreen separado. Hay algunas alternativas: coroutine , que no proporciona hilos verdes reales por ahora, y green-rs , que está roto. ¿Entiendo bien que, por ahora, no hay procesos livianos tipo Go en Rust?
Lea este https://aturon.github.io/blog/2016/08/11/futures/ y también:
La respuesta de Steve Klabnik en los comentarios:
Al principio, Rust tenía solo hilos verdes. Finalmente, se decidió que un lenguaje de sistemas sin subprocesos de sistemas es ... extraño. Así que necesitábamos añadirlos. ¿Por qué no añadir elección? Dado que las interfaces pueden ser las mismas, ¿por qué no abstraerlas y elegir la que deseaba?
Al mismo tiempo, los problemas con los hilos verdes por defecto se estaban convirtiendo en problemas. Las pilas segmentadas causan una interoperabilidad C lenta. Necesita un tiempo de ejecución para gestionarlos, etc. Además, la abstracción general estaba causando un costo inaceptable. Los hilos verdes no eran muy verdes. Además, con la necesidad de liberar algún día, se deben tomar decisiones con respecto a las compensaciones. Y dado que se supone que Rust es un lenguaje de sistemas, tener hilos 1: 1 y básicamente ningún tiempo de ejecución tiene más sentido que los hilos N: M y un tiempo de ejecución. . Así que se eliminó libgreen, la interfaz se volvió a hacer para estar centrada en 1: 1.
El ''lanzamiento que se avecina algún día'' es una gran parte de él. Queremos ser realmente estables con Rust, y con todas las cosas que hacer para enviar un 1.0, no queríamos cristalizar una interfaz con la que no estábamos contentos. Jeck, sacamos muchas bibliotecas que son aún menos importantes por razones similares, como rand. La ingeniería tiene que ver con compensaciones, y decidimos elegir el minimalismo.
mio no es un iniciador para nosotros, como lo son la mayoría de los otros marcos de trabajo de I / O async para Rust, porque necesitamos Windows y, además, no queremos quedarnos atrapados en una biblioteca costosa para reemplazar que puede quedar huérfana.
Totalmente entendido aquí, especialmente en el caso general. En el caso específico, mio tendrá soporte para Windows o se lanzará una versión específica de Windows para mio, con un paquete de nivel superior que proporciona las características para todas las plataformas. Y en este caso, es mantenido por una de las personas que actualmente utiliza Rust en gran medida en la producción, por lo que no es probable que desaparezca pronto. Pero, a menos que esté involucrado activamente, es difícil saber cosas como esa, lo cual es, en sí mismo, un problema.
Una de las razones por las que nos sentimos cómodos al eliminar libgreen es que puede escribir sus propias bibliotecas para realizar diferentes tipos de IO. 1.0 es un núcleo fuerte que nos hace sentir bien al estabilizarnos para siempre, no a la broca final. Las bibliotecas como mio pueden probar diferentes maneras de manejar cosas como IO asíncrono y, cuando están lo suficientemente maduras, siempre podemos recuperarlas en la biblioteca estándar si es necesario. Pero mientras tanto, es solo una línea para su Cargo.toml para agregarlos.
Y tal texto de reddit :
Desafortunadamente, terminaron envasando el soporte de Greenlet porque eran más lentos que los hilos del kernel, lo que a su vez demuestra que alguien no entendió cómo hacer que un compilador de lenguaje genere coroutines sin apilamiento de manera efectiva (no es sorprendente, el número de ingenieros conectados de la manera correcta no es mucho) en este mundo, pero consulte http://www.reddit.com/r/rust/comments/2l0a4b/do_rust_web_servers_use_libuv_through_libgreen_or/ para obtener más detalles). Y conservaron el i / o asíncrono porque libuv es "lento" (lo cual es solo porque es solo un hilo, además obliga a un malloc + libre por operación asíncrona, ya que los búferes deben durar hasta que se complete, y además impone una penalización por i / o síncrono ver http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html ), que fue una verdadera pena, deberían haber aprovechado la oportunidad para reemplazar libuv con algo mejor (pista: ASIO + AFIO, y sí, sé que ambos son C ++, pero Rust podría tener una interoperación de C ++ mucho mejor que la que actualmente no tiene) en lugar de enlatar siempre-asincrónico-todo en lo que podría haber sido un paso sorprendente desde C ++ con la mayoría de los beneficios de Erlang sin las desventajas de Erlang.
Para los recién llegados, ahora hay may , una caja que implementa hilos verdes similares a goroutines.
Tienes razón en que no hay una biblioteca de tareas ligeras en la coroutine (o en el resto de la distribución principal), que el green no se compila y que la coroutine no parece manejar completamente el aspecto del subproceso. No conozco ninguna otra biblioteca en este espacio.
En cuanto a lo que sucedió: el RFC vinculado a ese problema, el RFC 230, es la fuente canónica de información. El resumen es que se descubrió que el método por el cual se manejó el subproceso verde / IO (el std intentó abstraerse en ambos modelos, permitiéndoles que se usaran de forma automática e inoperable) no valía la pena. Ahora, std apunta simplemente a proporcionar una línea de base mínima de soporte útil: para IO / threading, eso significa envoltorios "delgados" y seguros para la funcionalidad del sistema operativo.