Здравствуйте, VladD2, Вы писали: VD>>>Не. Легкие потоки — это кооперативная многозадачность. Работает всегда только один поток и переключение осуществляется явно. MC>>А эрланг — это тогда кто? VD>В Эрланге за переключением следит интерпретатор.
Но потоки-то от этого тяжелее не стали
VD>Асинхронный ввод-вывод может быть реализован и без потоков вообще, если задействованы библиотеки ОС. Только вот внутри себя там используются потоки ОС и прерывания процессоров. Так что легкие потоки тут никаким боком.
Мне кажется, в этой точке мы достигли терминологического коллапса. Мой изначальный тезис был, что асинхронный ВВ и легкие потоки — два взгляда на одну задачу использования минимума потоков ОС с максимумом профита.
VD>Тут более уместен другой вопрос. А есть ли библиотеки (написанные на С, по всей видимости) для Эрланга которые реализуют этот самый асинхронный ввод-вывод?
Внезапно, я совершенно себе не представляю, как работает ввод-вывод в эрланге. Для легких потоков ВВ блокирующий — это понятно. А вот как с ВВ поступает сам рантайм — я хз. Слышал краем уха, что в итоге всем ВВ в асинхронном режиме занимается отдельный (или ограниченное число отдельных) ОС-поток рантайма.
Re[9]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
DM>>Подозреваю, человек намекал на asynchronous workflows. В Немерле они есть?
VD>Нет. Зато в Немерле есть макросы на базе которых аналогичные решения прикручиваются без вмешательства в компилятор.
Это ни разу не аналогичное решение. Тут на каждый чих создается поток, а там идет преобразование линейной программы в набор колбэков для асинхронных функций.
VD>К тому же asynchronous workflows немного из другой оперы. Асинхронный ввод-вывод в дотнете делается на базе стандартных классов потоков. Они являются обычными объектами дотнета и работать с ними удобнее из языка для которого дотнет родная среда.
Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, D. Mon, Вы писали:
DM>>Подозреваю, человек намекал на asynchronous workflows. В Немерле они есть?
VD>Нет. Зато в Немерле есть макросы на базе которых аналогичные решения прикручиваются без вмешательства в компилятор.
asynchronous workflows сделаны на поддержке монад (которые в F# называются Computation Expressions),
тоже без вмешательства в компилятор.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, achmed, Вы писали:
A>asynchronous workflows сделаны на поддержке монад (которые в F# называются Computation Expressions), A>тоже без вмешательства в компилятор.
Противоречишь сам себе. Если есть поддержка чего либо, то без вмешательства в компилятор не обошлось.
В случае же макросов эту самую поддержку можно реализовать действительно без вмешательства в компилятор. Или можно обойтись без нее и реализовать конкретную задачу (вроде поддержки паттерна работы с многопоточностью) напрямую.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[10]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, D. Mon, Вы писали:
DM>Это ни разу не аналогичное решение. Тут на каждый чих создается поток, а там идет преобразование линейной программы в набор колбэков для асинхронных функций.
Где, "там"? И можно услышать твое определение понятия "аналогичный"?
От себя замечу, что макросам по фигу что на них будут реализовывать. Главное, что если в языке чего-то нет, то это можно сделать не обращаясь к разработчикам языка и не разводя бодягу.
DM>Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Mr.Cat, Вы писали:
MC>Мне кажется, в этой точке мы достигли терминологического коллапса.
Возможно.
MC>Мой изначальный тезис был, что асинхронный ВВ и легкие потоки — два взгляда на одну задачу использования минимума потоков ОС с максимумом профита.
Я так и не увидел связи между легкими потоками и АВВ.
VD>>Тут более уместен другой вопрос. А есть ли библиотеки (написанные на С, по всей видимости) для Эрланга которые реализуют этот самый асинхронный ввод-вывод?
MC>Внезапно, я совершенно себе не представляю, как работает ввод-вывод в эрланге. Для легких потоков ВВ блокирующий — это понятно. А вот как с ВВ поступает сам рантайм — я хз. Слышал краем уха, что в итоге всем ВВ в асинхронном режиме занимается отдельный (или ограниченное число отдельных) ОС-поток рантайма.
Ну, то есть АВВ встроен в интерпретатор? Вот это и нужно было бы рассмотреть по подробнее.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Стоит ли использовать erlang для такой задачи?
Что "Пожалуйста" — это описание функции работы с сокетами. В Винде с файлами невозможно работать через АПИ сокетов.
T>И следущим аргументом (в уже непонятно каком споре) будет отсутствие каких-то биндингов в стандартной поставке?
Какой спор? Вопрос только в том есть ли в Эрланг возможность осуществления АВВ из коробки, и если нет, то сколь трудно создать такое решение.
T>Сигнал должен быть обработан ядром. Почему именно потоком?
Потому, что ядро это всего лишь область памяти доступная в некотором привилегированном кольце защиты. А выполнять код находящийся в этой памяти может только поток. По крайней мере в Винде это так.
T> Есть же однопоточный DOS. Железо его прервало, он обработал сигнал: поставил флаг и как-то там сообщил активной программе. АВВ есть, потоков нет.
В одноклеточном досе АВВ не было. Во время работы драйвера выполнение программы полностью останавливалось. На то это и называется прерывание.
T>Ну если так низко копать, то да, конечно, какая-то поддержка АВВ (как минимум, способ дёрнуть ядро) в языке должна быть. Ну так во всех и есть. К чему ты клонишь?
Ну, так пока что никто так и не указал есть ли в эрланге АВВ из коробки и если нет, то можно ли его реализовать учитывая, что потоки то кооперативные.
Обсуждений море, а четкого ответа нет. А это в сущности ответ на вопрос уместно ли применение эрланга в данной задаче, т.е. ответ на вопрос темы.
T>Влад, просто жесть уже началась. Аналог: "В винде дорогие процессы, поэтому многозадачное программирование на винде — неудачный пример." Аргументация достойная кого?
Я не могу гворить за симтему с корой знаком на уровне начинающего пользователя. Но от того же FR слышал, что в Питоне с параллелизмом труба.
T>Неудачный потому что демонстрирует возможность того, что ты опровергал выше?
А что я опровергал?
T>и моя позиция (с доказательствами) в том, что смысл АВВ несколько более абстрактен: просто не блокироваться на IO. Кажется (я уже не уверен) мы спорим о том, обязательно ли тут нужны ОС потоки.
А что толку с абстрактности когда ехать нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[16]: Стоит ли использовать erlang для такой задачи?
DM>>Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
VD>Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
на каких языках работать с асинхронными методами проще чем в F# ?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[13]: Стоит ли использовать erlang для такой задачи?
T>>И следущим аргументом (в уже непонятно каком споре) будет отсутствие каких-то биндингов в стандартной поставке? VD>Какой спор? Вопрос только в том есть ли в Эрланг возможность осуществления АВВ из коробки, и если нет, то сколь трудно создать такое решение.
Сетевой — точно из коробки.
На freenode #erlang сказали, что файловый тоже асинхронный, либо через неблокирующиеся вызовы ядра, либо через отдельные ОС треды, в любом случае, для программиста это прозрачно.
То есть, технически, да (и это само собой разумеется), Erlang для этой задачи подходит. Другой вопрос, что ни от его АВВ, ни от параллелизма тут большого выигрыша не будет, скорее всего в скорость диска всё упрётся.
T>>Влад, просто жесть уже началась. Аналог: "В винде дорогие процессы, поэтому многозадачное программирование на винде — неудачный пример." Аргументация достойная кого? VD>Я не могу гворить за симтему с корой знаком на уровне начинающего пользователя. Но от того же FR слышал, что в Питоне с параллелизмом труба.
С параллелизмом в питоне и руби полный п-дец. А с АВВ и лёгкими потоками всё нормально.
T>>Неудачный потому что демонстрирует возможность того, что ты опровергал выше?
VD>А что я опровергал?
Ну, не опровергал, отрицал что-ли... утверждал невозможность.
В общем, по любому языку должны быть доступна библиотека поддерживающая этот самый асинхронный ввод-вывод. Если она есть, действительно уже по фигу что там в языке с потоками творится. А если ее нет, то реализовать ее на кооперативных потоках не удастся. Нужны нормальные потоки.
Вот я привёл пример, когда АВВ реализован библиотекой на кооперативных потоках (которые тоже реализованы библиотекой) и без ОС потоков.
Re[12]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, cadet354, Вы писали:
VD>>Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
C>на каких языках работать с асинхронными методами проще чем в F# ?
Долго искал связь между моими словами и данным вопросом. Потом долго пытался понять кто такие асинхронные методы и чем они отличаются от обычных. Ответов так и не наше.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, Temoto, Вы писали:
T>Сетевой — точно из коробки.
Кто такой "Сетевой"? Вроде как речь шла о сравнении файлов.
T>На freenode #erlang сказали, что файловый тоже асинхронный, либо через неблокирующиеся вызовы ядра, либо через отдельные ОС треды, в любом случае, для программиста это прозрачно.
Обычно когда на вопрос могут ответить да или нет, то отвечают да или нет. И если на такой вопрос начинают давать развернутый ответ, то... .
T>То есть, технически, да (и это само собой разумеется), Erlang для этой задачи подходит. Другой вопрос, что ни от его АВВ, ни от параллелизма тут большого выигрыша не будет, скорее всего в скорость диска всё упрётся.
Вот это уже более конкретно.
T>Ну, не опровергал, отрицал что-ли... утверждал невозможность.
Да, ну?
Я всего лишь пытался людей подвигуть в конструктивное русло. Если нужные возможности есть, то хорош бы просто указать на них. Если нет, то описать как их достичь (хотя эту уже повод задуматься о том насколько инструмент подходит для решения задачи).
T>
В общем, по любому языку должны быть доступна библиотека поддерживающая этот самый асинхронный ввод-вывод. Если она есть, действительно уже по фигу что там в языке с потоками творится. А если ее нет, то реализовать ее на кооперативных потоках не удастся. Нужны нормальные потоки.
T>Вот я привёл пример, когда АВВ реализован библиотекой на кооперативных потоках (которые тоже реализованы библиотекой) и без ОС потоков.
Да, ну? А может реализованы в библиотеке которая написана на низкоуровневом языке?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[15]: Стоит ли использовать erlang для такой задачи?
В общем, по любому языку должны быть доступна библиотека поддерживающая этот самый асинхронный ввод-вывод. Если она есть, действительно уже по фигу что там в языке с потоками творится. А если ее нет, то реализовать ее на кооперативных потоках не удастся. Нужны нормальные потоки.
T>>Вот я привёл пример, когда АВВ реализован библиотекой на кооперативных потоках (которые тоже реализованы библиотекой) и без ОС потоков.
VD>Да, ну? А может реализованы в библиотеке которая написана на низкоуровневом языке?
При отсутствии более эффективных библиотек, eventlet прозрачно использует свой микрослой без низкоуровневых языков.
Откуда эта убеждённость, зачем спор? У тебя был неудачный опыт по повооду АВВ без Си что-ли?
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
DM>>Это ни разу не аналогичное решение. Тут на каждый чих создается поток, а там идет преобразование линейной программы в набор колбэков для асинхронных функций.
VD>Где, "там"?
В asynchronous workfows. Советую с ними познакомиться, прежде чем продолжать.
VD>И можно услышать твое определение понятия "аналогичный"?
В данном случае: похожий, работающий схожим образом, решающий ту же задачу.
DM>>Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
VD>Вот это огромное заблуждение. Для F# дотнет среда не родная.
Для F# нет среды роднее. Если есть — покажи ее.
VD> F# — это адаптированный к дотнету ОКамл.
А Немерле — адаптированный к дотнету Паскаль. Возможно, исторически F# и вдохновлен окамлом, но сейчас между ними различий больше, чем сходств.
Re[11]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, achmed, Вы писали:
A>>asynchronous workflows сделаны на поддержке монад (которые в F# называются Computation Expressions), A>>тоже без вмешательства в компилятор.
VD>Противоречишь сам себе. Если есть поддержка чего либо, то без вмешательства в компилятор не обошлось.
Computation Expressions это изначально часть языка F#
VD>В случае же макросов эту самую поддержку можно реализовать действительно без вмешательства в компилятор. Или можно обойтись без нее и реализовать конкретную задачу (вроде поддержки паттерна работы с многопоточностью) напрямую.
А на Nemerle можно сделать поддержку синтаксического сахара для монад, который в Haskell называется "do синтаксис"?
Re[13]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, cadet354, Вы писали:
VD>>>Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
C>>на каких языках работать с асинхронными методами проще чем в F# ?
VD>Долго искал связь между моими словами и данным вопросом. Потом долго пытался понять кто такие асинхронные методы и чем они отличаются от обычных. Ответов так и не наше.
странно, когда это написал D.Mon ты понял о чем речь
DM>Да, делается на базе стандартных классов. Да, для F# дотнет родная среда. Да, на F# конкретно с асинхронными методами работать удобнее, чем на любом другом дотнет языке.
Вот это огромное заблуждение. Для F# дотнет среда не родная. F# — это адаптированный к дотнету ОКамл. Я не раз слышал от других людей о том, что это создает проблемы.
там ты просто ушел от ответа, т.к. в F# работать с APM (надеюсь этот акроним расшифровывать не надо) действительно очень, очень удобно:
open System
open System.Net
open Microsoft.FSharp.Control.WebExtensions
let http url =
async { let req = WebRequest.Create(Uri url)
use! resp = req.AsyncGetResponse()
use stream = resp.GetResponseStream()
use reader = new StreamReader(stream)
let contents = reader.ReadToEnd()
return contents }
let sites = ["http://www.bing.com";
"http://www.google.com";
"http://www.yahoo.com";
"http://www.search.com"]
let htmlOfSites =
Async.Parallel [for site in sites -> http site ]
|> Async.RunSynchronously
где в .NET удобнее?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[12]: Стоит ли использовать erlang для такой задачи?
Здравствуйте, achmed, Вы писали:
A>Computation Expressions это изначально часть языка F#
Во как? А я их вроде бы в 2007 году не видел. Мне показалось?
А так да. Все что гвоздями прибито к компилятору становится частью языка.
A>А на Nemerle можно сделать поддержку синтаксического сахара для монад, который в Haskell называется "do синтаксис"?
Естественно, да. Только не очень нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Вирт был бы в шоке, если бы узнал об этом. 