Здравствуйте, Cyberax, Вы писали:

C>Не рулят. Фибры — весьма глючны, непортабельны, давно не развиваются и
C>не дают много преимуществ.
C>http://blogs.msdn.com/larryosterman/archive/2005/01/05/347314.aspx

Файберы — рулят, ни разу не глючны, на портабельность плевать — будут проблемы и похуже при попытке портировать нечно с Win32 (хотя аналоги есть и в Unix под названием user-level threads), развиваться там нечему — все крайне просто (весь API — вызовов 6), и даже если бы не было файберов в API, их можно было бы написать ручками на asm-е.

И разумеется, файберы дают массу преимуществ при грамотном использовании. Применение файберов в рамках legacy-продуктов CQG позволило нам более чем вдвое удешевить разработку и рефакторинг некоторых подсистем клиента и сервера. Про глючность — выдумки, у нас уже три года сервера на файберах крутятся, и ни одной проблемы с ними не было.

Что касательно производительности — накладные расходы на переключение файбера мизерные по сравнению и с переключением контекста потока, и с раскруткой стека при коллбэчном асинхронном стиле программирования, что позволяет применять их совершенно по другому — плодить их в большом количестве, часто переключать контексты, и т.д. Короче, файберы рулят со страшной силой.

Статья эта — отстой полный.

They're also HARD to deal with — you essentially have to write your own scheduler.

Ай-ай-ай. Как раз поэтому файберы и хороши, что можно (но совсем не обязательно) писать свой шедулер. Наш шедулер занимает 468 строк на С++. Пишется за пару недель. И он очень хорош, просто великолепен. Управляется с приоритетами так, как нужно нам, а не оперсистеме, и работает нормально на том количестве параллельных активностей, которая удобна нам, а не разработчикам ядра. Нам, например, удобно, чтобы их было порядка 10К, а не идиотская сотня с идиотскими пулами.

Далее, я написал очень много файберного кода, и как врач говорю, что в нем существенно реже возникают проблемы синхронизации даже при использовании той же самой модели разделяемых данных. Файбер не может прерваться в любой момент, вы сами говорите ему — где, что сильно уменьшает как количество примитивов синхронизации в вашей программе, так и упрощает доказательство корректности программ. Файберный код — более надежен, чем потоковый, его проще писать, и его проще отлаживать.

Второй момент — на файберах удобно реализовывать сопрограммы и continuations. Что не требует планировщика — автор очевидно этот случай вообще не рассматривает. Афтарлох, короче.

The other reason that fibers have remained obscure is more fundamental. It has to do with Moore's law (there's a reason for the posts yesterday and the day before).

Ну-ну. Закон Мура что-то не помогает виндам чувствовать себя нормально хотя-бы с 1К потоков на процесс — я уже не говорю о большом количестве активно взаимодействующих потоков, которые часто переключаются и жрут мало CPU на обработку одной мессаги. То есть в том сценарии, когда мы в процентах много теряем на переключение контекста — мы продолжим терять столько же. И закон Мура ровным счетом никак не помогает.