Легкие потоки

Чтобы потоки нормально себя чувствовали - сущности в системе должны быть практически все иммутабельные...

Чего это вдруг? В go потоки нормально себя чувствуют, при том, что иммутабельности там особо нет.

Чтобы потоки нормально себя чувствовали, должна быть хорошо продумана схема взаимодействия между потоками. И тут возможны разные варианты.

легкие зеленые потоки
как такое самому сделать

посиди со знакомыми, у которых они уже есть. Обеспечено будет. Главное — не принимай чеснока и прочих "антигриппинов".

Дык, если бы тот человек не объявился, то и 7.8 бы не было, про его планы в фиксе других багов я не в курсе. Есть конечно шанс что IHG (Industrial Haskell Group) хоть чуть-чуть заинтересованы в виндах и оплатят работу по фиксу проблем на win, но пока этого, насколько мне известно, не случалось.

Есть конечно шанс

Aha, fat chance.

Дело в том что костылями дело уже не поправишь. Нужно перепроектировать хотя бы части base, как минимум касающиеся работы с хендлами и I/O.

Иначе, хрен нам а не высокопроизводительные I/O приложения под вендой.

Это, кстати, касается всех. «Зеленые» потоки и так лютый ужас с точки зрения проектирования, а сделать их еще и переносимыми под онтопик/офтопик/FreeBSD/Mac — вообще адЪ.

И создание собственной ВМ, как не странно, это наиболее простой, прямолинейный и дуракоустойчивый способ реализации.

В go потоки нормально себя чувствуют, при том, что иммутабельности там особо нет.

Иммутабельность иммутабельности рознь. Если говорить о мутабельности в рамках одного процесса, то всё более-менее просто...

А вот если говорить о мутабельности с точки зрения системной среды, то уже начинаются приколы. Как минимум, никаких блокирующих вызовов быть не должно.

Дело в том что костылями дело уже не поправишь.

мне очень интересно твое определение слова «костыли» и реальные примеры (не сарказм).

Нужно перепроектировать хотя бы части base, как минимум касающиеся работы с хендлами и I/O.

одно другому не мешает, причем переработка base для винды совершенно не зависит от rts и наоборот.

«Зеленые» потоки и так лютый ужас с точки зрения проектирования,

ты пропустил слова «на мой взгляд» ;)

а сделать их еще и переносимыми под онтопик/офтопик/FreeBSD/Mac — вообще адЪ.

т.е. под виндой не работает forkIO? Насколько я помню под виндой проблемы с неблокируемыми вызовами, т.к. они там не делаются, исправь в base чтобы все вызовы для работы с вводом-выводом были неблокирующимися и rts-пиналась при появлении событий (аналог *poll) и будет тебе счастье.

И создание собственной ВМ, как не странно, это наиболее простой, прямолинейный и дуракоустойчивый способ реализации.

я честно не знаю как это вменяемо прокомментировать :/

как такое самому сделать?

рецепт прост: когда будешь придумывать свой собственный язык — встрой в этот язык эту возможность (Green Threads работают на уровне языка, а не на уровне библиотеки.. так как эти threads сделаны более просто и более топорно более некачественно [чем настоящие Native Threads] поэтому они и получаются более «лёгкими»).

и ещё, «thread» переводится как «нить». где вы слово «поток» услышали..

мне очень интересно твое определение слова «костыли»

Костыли, это когда что-то делают под позксо-линукс (или линуксо-позикс), а потом начинают ломать голову, как же это запилить на венде.

В венде, например, семантика IOCP кардинально отличается от epoll и дескрипторы сокетов и файлов — разные сущности, на один системный поток может быть только один IOCP и хрен его еще знает сколько «нюансов».

Семантика потоков отличается от pthread. Вроде бы как можно сделать полноценную реализацию pthread на современной (виста и т.д.) венде, но *всем* глубоко положить.

исправь в base чтобы все вызовы для работы с вводом-выводом были неблокирующимися

Всё не так просто. https://ghc.haskell.org/trac/ghc/ticket/7353 заглохло пару лет назад по причине «It's more complicated than I expected».

И это ведь только base!

Короче, всё плохо, мы все умрем ;)

IOManager это весьма низкоуровневая фигня и должна решаться платформо-специфично. То, что IOManager для винды нету это печально, но я так и не понял, где тут костыли?

И это ведь только base!

нужен IOManager и интерфейс в base, что в этом контексте обозначает «только»?

Под виндами, все плохо - да. Там кстати только со -threaded все плохо или с обычной rts тоже?

Вроде бы как можно сделать полноценную реализацию pthread на современной (виста и т.д.) венде, но *всем* глубоко положить.

А что ее там делать? Я так сходу не вижу, что такое есть в pthread, чего нету в WinAPI. Обычно проблемы портирования возникают в основном в обратную сторону.

Я так сходу не вижу, что такое есть в pthread, чего нету в WinAPI.

Я тоже не вижу. А вот полноценной реализации под венду — нет. Cygwin не в счёт.

Можно сделать stackless сопрограммы на switch и паре макросов. Готовых реализаций много. Можно взять всякие библиотеки для сохранения/переключения контекста, на чем можно сделать stackfull сопрограммы.

И то, и другое есть в boost. Stackless в asio есть, а остальное в виде отдельных библиотек. Так же есть ещё не вошедший в boost boost.task

А вот полноценной реализации под венду — нет. Cygwin не в счёт.

А что в сигвине не так?

А что в сигвине не так?

Цыгвин возомнил себя отдельностоящим юниксом, и для виндовых приложений типа того же GHC, или того что получается с помощью GHC, он не сильно подходит.

И че? Так а что в его pthread не так?