В чем принципиальное отличие тредов и user-level нитей?

До тех пор пока не заблокируешься на сисколе или ffi-вызове.

man вытесняющая многозадачность vs кооперативная многозадачность.

Сопрограммы дадут тебе второе.

Плюс одним потоком не загрузишь 2 ядра CPU, но это очевидно даже тебе.

Ты имеешь в виду явным образом не загрузишь, правильно я понял? Ведь VM однопоточного языка на своем уровне все равно шарит процесс между ядрами?

Да что бы она там ни делала — 2 зелёных треда не будут выполняться одновременно (иначе код сломается: он не рассчитан на это). От того, что ни будут скакать по ядрам, будет только вред и лучше сделать pinning.

Привет!

Зависит от RTS. Что-то js подобное так делать не будет, RTS Erlang или Haskell легко раскидают зелёные потоки по OS потокам.

Haskell легко

хаскель легко, кто бы в этом сомневался. У него даже репл есть. И он даже иногда не тормозит, а иногда даже не падает. Программы на хаскеле в последнее время стали компилироваться молниеносно, менее 2 часов. Зависимостей почти не тянут, не более пятисот, на прогу, во всяком случае.

Правда от количества ядер это все слабо почему то-зависит. Заговор.

Зависит от RTS

Не, в первую очередь от TTD.

Круто конечно написано, жаль что только не про этот мир, даже положительные предположения

Умерь пыл, а то этот аккаунт и дня не проживет.

Конечно не про этот. В этом, чистом мире времени вообще нет.

Разные реализации имеют разные плюсы и минусы. При чём тут системные вызовы и ОС-потоки, я не знаю. Никаких тормозов у ОС-потоков нет. Максимум — проблема масштабирования на огромное число потоков.

Ведь VM однопоточного языка на своем уровне все равно шарит процесс между ядрами?

Ммм, что еще интересного расскажешь? Я бы хотел услышать о примерах подобного поведения, например.

А если, они нативные?

«Нативные» потоки это, внезапно, и есть реализация 1x1 на ОС потоках. Делать отличные схемы от 1x1 есть смысл если получится существенно уменьшить оверхед на контекст потока или если ОС не умеет потоки. Во всём остальном софтварные потоки приносят тормоза и кучу прочих недостатоков.

Эм.. Какого черта в но фичи которым меньше 30 лет?!

Делать отличные схемы от 1x1

Там получаются не отличные, а вообще независимые от ОС. Смысл есть хотя бы ради масштабируемости.

Например:

Io uses coroutines (user level cooperative threads), instead of preemptive OS level threads to implement concurrency. This avoids the substantial costs (memory, system calls, locking, caching issues, etc) associated with native threads and allows Io to support a very high level of concurrency with thousands of active threads.

Я правильно понял, что ты написал, что во всем остальном программы построенные вокруг select/poll/epoll приносят тормоза и кучу других недостатков?

Я правильно понял, что ты написал, что во всем остальном программы построенные вокруг select/poll/epoll приносят тормоза и кучу других недостатков?

Если будешь на них делать потоки в юзерспейсе, до да, правильно понял (т.е. делать свою реализацию libс которая будет заворачивать все блокирующие вызовы через свою асинхронную кухню, управлять контекстами через ~ {get,set}context() и т.д.). Но вообще, конечно, ты всё понял не правильно.

ok.. так и запишем, спасибо за развернутый ответ, вопросов больше не имею.

Это их selling point, поэтому можно в качестве исключения.

кстати я ошибся, статья об организации их модели от 78 года Хоара (правда сейчас уже развитие ушло дальше), так что все норм.

правда сейчас уже развитие ушло дальше

Конечно ушло, ведь хоар обосрался

The version of CSP presented in Hoare's original 1978 paper was essentially a concurrent programming language rather than a process calculus. It had a substantially different syntax than later versions of CSP, did not possess mathematically defined semantics,[10] and was unable to represent unbounded nondeterminism.[11] Programs in the original CSP were written as a parallel composition of a fixed number of sequential processes communicating with each other strictly through synchronous message-passing. In contrast to later versions of CSP, each process was assigned an explicit name, and the source or destination of a message was defined by specifying the name of the intended sending or receiving process

А поэтому, пришлось пилить все заново. Правда дядя себя сильно не стал утруждать, просто приспособил уже существовавшую на тот момент модель акторов. История, повторилась в который раз.

В итоге дяденька скатился до Microsoft Research

И, кстати, твой хаскелек тоже это говнецо стороной не обошло

Haskell MVars are a rendezvous mechanism for synchronizing threads — это, по-ходу, влияние CSP

а все потому, что STM не поддерживает rendezvous ну никак. Впрочем модель актеров подобного примитива тоже не содержит.

В модели акторов нет свистелок и перделок. Там есть только один примитив — актор. А суть в том, что первоначальная версия CSP на которую ты указал, оказалась несостоятельна, и хоар ее перекраивал, пользуясь идеями, заимствованными из модели Акторов.

Тест

Угадал автора по заголовку

В модели акторов

Чет анонимусы за все твои треды так и не смогли найти эту самую модель. Сам ты ее никому не показал, естественно.

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

Сам ты ее никому не показал, естественно.

А ты не сомневаешься в существовании Путина? Может тебе пруфец подкинуть?