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

_>>А чем тут поможет лямбда? )Мы же про parallel_map говорим, правильно? )
EP>В случае с parallel_map можно использовать ленивый список индексов по типу boost::irange

Да, в C++ можно так извратиться) А в Эрланге? )

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

_>>При схеме N лёгких на N системных будет почти одинаково (с поправкой на обработку бесполезных вызовов yield в случае лёгких).
BZ>а чем эрланг хуже?

Тем, что там грубо говоря yield'ы (и ещё куча мусора) раскиданы по всему коду, причём ты на это никак повлиять не можешь.

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

F>>>>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка.
_>>>Ну так в случае асинхронного IO это физически невозможно)
F>>это почему это?
_>Ну потому что асинхронное IO в принципе не блокируется.

так IO не заблокируется. заблокируется обработчик и свяжет всё остальное.

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

_>Ну т.е. мы не можем написать на Эрланге аналог такого простейшего многопоточного кода? )

слово-в-слово — нет. потому что язык другой.
удивительно, правда?

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

_>Тем, что там грубо говоря yield'ы (и ещё куча мусора) раскиданы по всему коду, причём ты на это никак повлиять не можешь.

вот и настал тот день, когда тебе уже пора нести пруфы своим утверждениям.

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

F>так IO не заблокируется. заблокируется обработчик и свяжет всё остальное.

Как заблокируется то, если блокирующих вызовов ОС нет? ) Разве что специально накосячить, вставив там мьютексы какие-то... )

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

_>>Ну т.е. мы не можем написать на Эрланге аналог такого простейшего многопоточного кода? )
F>слово-в-слово — нет. потому что язык другой.
F>удивительно, правда?

Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге.

_>>Ну т.е. мы не можем написать на Эрланге аналог такого простейшего многопоточного кода? )

F>слово-в-слово — нет. потому что язык другой.
F>удивительно, правда?

Более того, гораздо интереснее вопрос о том, что будет, когда пример усложнится. Видимо, надо будет «выбирать из десятка библиотек» или «там руками пару catch'ей поставить» и тому подобное

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

_>>Тем, что там грубо говоря yield'ы (и ещё куча мусора) раскиданы по всему коду, причём ты на это никак повлиять не можешь.
F>вот и настал тот день, когда тебе уже пора нести пруфы своим утверждениям.

Хыхы, а как ты думал реализована та самая "возможность прерывания потоков"? ) Магия что ли? )))

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

_>>>Тем, что там грубо говоря yield'ы (и ещё куча мусора) раскиданы по всему коду, причём ты на это никак повлиять не можешь.
F>>вот и настал тот день, когда тебе уже пора нести пруфы своим утверждениям.
_>Хыхы, а как ты думал реализована та самая "возможность прерывания потоков"? ) Магия что ли? )))

пруфов нет, окай.

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

_>Как заблокируется то, если блокирующих вызовов ОС нет? ) Разве что специально накосячить, вставив там мьютексы какие-то... )

это

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

_>Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге.

такой же, если берётся сторонняя библиотека/модуль.
и короче, если у плюсов тоже отнять стороннюю библиотеку.

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

F>>>>приходит сообщенька по сети, тред её обрабатывает и уходит в дедлок/ожидание внешнего ресурса/что-то-ещё. вот и блокировка.
_>>>Ну так в случае асинхронного IO это физически невозможно)
F>>это почему это?

_>Ну потому что асинхронное IO в принципе не блокируется.

Блокируется не IO, а конкретный поток. Если у тебя основная логика в одном потоке, то в него нужно диспетчеризовать всё, что идет от IO. Вот с такой диспетчеризацией проблемы — она делается исключительно через event loop.

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

M>Все просто. Мы запустили поток, нам нужно:
M>- Знать, что поток выполняется
M>- Знать, когда поток завершится, и узнать, как поток завершился (вернул значение, вылетел с ошибкой)
M>- Возможно, перезапустить поток, если он завершился
M>- Убить поток, если это необходимо

Зачем все это?

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

Я уж не говорю о том, что есть три причины использовать потоки, они принципиально разные:
1. Чтобы раскидать работу по нескольким процессорам (фактически, это обход аппаратного ограничения; мы умеем делать многопроцессорные машины, но не умеем делать достаточно производительных процессоров)
2. Потому, что некоторым кажется, что программу, которая одновременно делает несколько дел, так проще писать. Хотя непродуманное взаимодействие между процессами убивает всё упрощение.
3. Потому, что иногда это единственный способ обойти ограничение операционной системы или той среды программирования, в которой приходится писать. Например, если надо ждать 2 разнотипных события, и в один WaitForMultipleSumething их одновременно не засунешь, не остается выбора, кроме как разбросать это дело по нескольким потокам.

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

M>

M>http://erlang.org/pipermail/erlang-questions/2012-February/064321.html

M>Any sufficiently complicated concurrent program in another language contains an ad hoc informally-specified bug-ridden slow implementation of half of Erlang.

Я уже слышал раньше эту фразу. Только вместа с;пва "Erlang" было слово "LISP"

M>Не обязательно потому что люди обязательно вдохновляются Erlang'ом, нет. А потому что Erlang раньше большинства многих других пришел к тому, к чему сейчас только приходят в других языках (и их библиотеках).

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

В эрланге это ограничение не очень заметно, потому что он — функциональный язык с иммутабельными данными, и уж раз данные в нем иммутабельны, то изоляция контекстов процессов особо ни на что и не влияет. Эрлангу не становится хуже от отсутствия общей памяти, потому что даже если бы она и была, с ней мало чего можно было бы сделать. Но вот в Си это не так.

Потоки, имеющие доступ к общим данным (общей памяти) и прочим системным ресурсам нужны только для эффективности. С точки зрения корректности кода (наплевав на эффективность) вполне можно было бы обойтись взаимодействующими процессами. Но слишком уж большую цену придется платить, если на каждый пук, чтобы передать данные от процесса к процессу, придется городить какой-нибудь message passing.

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

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

_>>Не, не, я не настаиваю на точно таком виде. Можно пользоваться любыми инструментами языка. Меня интересует всего лишь один простой вопрос: какой объём кода будет у реализации подобной (в смысле результата) многопоточной обработки данных на Эрланге.
F>такой же, если берётся сторонняя библиотека/модуль.

Ну т.е. у Эрланга нет нормальной поддержки многопоточности из коробки, правильно? )

F>и короче, если у плюсов тоже отнять стороннюю библиотеку.

OpenMP реализовано в компиляторе C++ (а так же C и Fortran), а не в виде сторонней библиотеки.

Pzz>Основные сложности и непонятки с потоками начинаются вовсе не вокруг их создания/завершения, а на тему, как организовать их совместную работу, чтобы все были заняты делом и никто никому не мешал.
Pzz>И вот для начала людям стоило бы научиться рефлектировать, почему они вообще выбрали многопоточную модель для решения той или иной задачи. А потом продумать, как они будут делить данные между потоками. И в принципе, я не очень понимаю, какая поддержка в языке для этого нужна.

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

Pzz>Эрлангу так хорошо живется потому, что в нем, как бы это сказать помягче, нет потоков. В нем есть взаимодействующие процессы. Каждый из которых полностью изолирован от других, и общается с ними только через специально приспособленные отверстия. Любой из эрланговских процессов можно поместить в отдельное адресное пространство, или даже утащить на другую машину, семантика от этого не изменится.

Не суть важно. Особой разницы — потоки это или процессы с точки зрения необходимости ... как там ... ах да, создавать, управлять, взаимодействовать. Сам же говоришь, с этим проблема

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

_>Ну т.е. у Эрланга нет нормальной поддержки многопоточности из коробки, правильно? )

нет, только там и есть нормальная))0)

F>>и короче, если у плюсов тоже отнять стороннюю библиотеку.
_>OpenMP реализовано в компиляторе C++ (а так же C и Fortran), а не в виде сторонней библиотеки.

не только в компиляторе.

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

M>То есть проблемы с созданием потоков, управлением потоков и взаимодействием потоков. Но «зачем на это нужно на уровне языка, не понимаю»

Ну понимаешь, если слово mutex станет ключевым словом языка, а не частью названия библиотечной функции, жизнь от этого особо не изменится.

А ничего шибко более умного пока и не придумано.

M>Не суть важно. Особой разницы — потоки это или процессы с точки зрения необходимости ... как там ... ах да, создавать, управлять, взаимодействовать. Сам же говоришь, с этим проблема

Как раз, важно. Потоки отличаются от процессов тем, что у потоков есть общая память и общие, хм, объекти операционной системы (файловые хендлы, сокеты и т.п.).

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

_>>Ну т.е. у Эрланга нет нормальной поддержки многопоточности из коробки, правильно? )
F>нет, только там и есть нормальная))0)

Ну тогда ты без проблем продемонстрируешь реализацию того элементарного примера (который на C++ занимает 2 строчки), не так ли? )

F>>>и короче, если у плюсов тоже отнять стороннюю библиотеку.
_>>OpenMP реализовано в компиляторе C++ (а так же C и Fortran), а не в виде сторонней библиотеки.
F>не только в компиляторе.

Не суть, главное что идёт в поставке компилятора, т.е. есть из коробки.

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

_>>>Ну т.е. у Эрланга нет нормальной поддержки многопоточности из коробки, правильно? )
F>>нет, только там и есть нормальная))0)
_>Ну тогда ты без проблем продемонстрируешь реализацию того элементарного примера (который на C++ занимает 2 строчки), не так ли? )

я тебе уже сказал. но ты не хочешь читать, почему-то.

F>>>>и короче, если у плюсов тоже отнять стороннюю библиотеку.
_>>>OpenMP реализовано в компиляторе C++ (а так же C и Fortran), а не в виде сторонней библиотеки.
F>>не только в компиляторе.
_>Не суть, главное что идёт в поставке компилятора, т.е. есть из коробки.

когда не надо, то не суть? отличный пример демагогии.