Что случилось с libgreen?

Ответ 1

Вы правы, что в std (или в остальной части основного дистрибутива) нет легкой библиотеки задач, которая green не компилируется и что coroutine, похоже, не полностью обрабатывает аспект многопоточности, Я не знаю никакой другой библиотеки в этом пространстве.

Что касается того, что произошло: RFC, связанный с этой проблемой, RFC 230 - это канонический источник информации. Резюме состоит в том, что было обнаружено, что метод обработки зеленой резьбы /IO (std пытался абстрагироваться по обоим моделям, что позволяло их использовать в автоматическом режиме) не стоило недостатков. Теперь std стремится предоставить минимальную базовую линию полезной поддержки: для ввода/вывода/потоковой передачи это означает "тонкие", безопасные оболочки для функциональных возможностей операционной системы.

Ответ 2

Прочтите этот https://aturon.github.io/blog/2016/08/11/futures/, а также:

ответ Стив Клабник в комментариях:

В начале у Руста были только зеленые нити. В конце концов, это было решил, что системный язык без системных потоков... странный. Поэтому нам нужно было добавить их. Почему бы не добавить выбор? Поскольку интерфейсы может быть одинаковым, почему бы не абстрагироваться от них, и вы могли бы просто выберите, который вы хотели?

В то же время проблемы с зелеными потоками по умолчанию были становятся проблемами. Сегментированные стеки вызывают медленное взаимодействие C. Тебе необходимо для управления ими и т.д. Кроме того, общая абстракция была вызывая недопустимую стоимость. Зеленые нити были не очень зелеными. Кроме того, с необходимостью фактически выпустить когда-нибудь надвигающиеся решения необходимо сделать в отношении компромиссов. А так как Руст должен быть системным языком, имеющим 1:1 потоки и в основном без времени выполнения имеет больше смысла, чем потоки N: M и время выполнения., Так что libgreen был удален, интерфейс был повторен, чтобы быть ориентированным на 1:1.

---

"Релиз когда-нибудь надвигающийся" - большая его часть. Мы хотим быть действительно стабильный с Rust, и со всеми вещами, которые нужно сделать на самом деле корабль 1.0, мы не хотели кристаллизовать интерфейс, который мы не счастлив с. Черт, мы вытащили много библиотек, которые еще меньше важно по тем же причинам, что и рэнд. Инженерия - все о компромиссы, и мы решили выбрать минимализм.

mio - это не стартер для нас, как и большинство других асинхронных i/o-фреймворков для Rust, потому что нам нужна Windows и, кроме того, мы не хотим   закрепить в дорогостоящей замене библиотеки, которая может получить   осиротел.

Полностью понятен здесь, особенно в общем случае. в конкретный случай, mio ​​будет либо иметь поддержку Windows, либо будет выпущена версия mio для Windows, с пакет более высокого уровня, предоставляющий функции для всех платформ. И в в этом случае он поддерживается одним из людей, которые в настоящее время используют Ржавчина сильно растёт, поэтому она вряд ли уйдет в любое время скоро. Но, если вы не принимаете активное участие, трудно знать вещи как это, что само по себе является проблемой.

Одной из причин, по которым нам было удобно удалять libgreen, является то, что вы могут писать собственные библиотеки, чтобы делать разные типы ввода-вывода. 1.0 является сильное ядро, что мы чувствуем себя хорошо о стабилизации навсегда, а не в финале немного. Библиотеки, такие как https://github.com/carllerche/mio, могут тестировать различные способы обработки таких вещей, как async IO, и, когда они достаточно зрелые, мы всегда можем вернуть их в стандартную библиотеку, если требуется. Но в то же время, это всего лишь одна строка для вашего Cargo.toml добавьте их.

И такой текст из reddit:

К сожалению, они закончили консервировать поддержку родословной, потому что они были медленнее, чем ядра, которые, в свою очередь, демонстрируют кто-то не понял, как получить компилятор языка для генерации (неудивительно, что количество инженеров, проводящих правильный путь, не так много в этом мире, но см. http://www.reddit.com/r/rust/comments/2l0a4b/do_rust_web_servers_use_libuv_through_libgreen_or/для более подробной информации). И они консервировали асинхронный ввод-вывод, потому что libuv "медленный" (что происходит только потому, что он однопоточный, плюс заставляет malloc + free за операцию async, так как буферы должны длиться до тех пор, пока не произойдет завершение, плюс оно наложит штраф за синхронный i/o см. http://blog.kazuhooku.com/2014/09/the-reasons-why-i-stopped-using-libuv.html), что было настоящим позором - они должны были воспользоваться замените libuv на что-то лучшее (подсказка: ASIO + AFIO, и да, я знаю они оба являются С++, но Rust мог бы сделать намного лучше С++ interop, чем в настоящее время нет в настоящее время) вместо консервирования всегда-асинк - все, что могло быть удивительным шагом вверх от С++ с большинством преимуществ Erlang без недостатков Эрланг.