Аналог java.util.concurrent.Future для LISP

и это все?

т.е. это фича gcc и icc? xa-xa-xa

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

> Значит там нету жавы.

Есть там жава. Просто она работает в специфической песочнице. Точно так же можно «доказать», что в Java не работают файловые операции - апеллируя к тому, что, дескать, Java-апплеты в браузере не имеют доступа к локальным файлам.

А dave — обычный демагог, коих немало среди лисперов. Что делать, приходится отстаивать честь своего фетиша в Специальной Олимпиаде. Потому что IRL что-то не получается, ой-вей.

> Ой-вей, Java и C++ обвешаны костылями! Только вот почему-то на них задача вызова асинхронных операций решается в три строки, а Б-жественный Лишп вообще CANNOT INTO эффективная многопоточность.

зажигай дальше, ага

Если я говорю java, то я имею в виду определенный набор спецификаций. Для апплетов спецификация не подразумевает работу с файлами. Какому набор спецификаций (JSR) соответсвует апенжиновская жава? Скорее всего это подмножество JavaSE, т.е. не Java. Так же как и андройдовская жава нифига не жава.

> Только вот почему-то на них задача вызова асинхронных операций

решается в три строки

Вы померяли, сколько строк для этого надо в лиспе?

Б-жественный Лишп вообще CANNOT INTO эффективная многопоточность.

4.2 же

> т.е. это фича gcc и icc? xa-xa-xa

Это стандарт.

и это все?

А что тебе надо ещё, MSVC? Так бы и сказал, что ты вантузнятник.

Так вот, MSVC поддерживает std::thread начиная с 2008 SP1. Или тебе нужна маргинальщина типа tcc? Во-первых, она и так не реализует половины стандартов, а во-вторых, на неё всем по*уй.

Кроме лиспотролля с баттхёртом от того, что быдлоЖаба и быдлоПлюсы уделали его кумира одной левой.

И ваапще, No Cl, make Clojure

> Вы померяли, сколько строк для этого надо в лиспе?

Явно больше, чем в C++/Java. Потому что библиотечного решения, удовлетворяющего требованиям ТСа (таймауты, пулинг, переносимость), пока что приведено не было.

Или вы считаете, что небиблиотечное (читай — велосипедное) решение займёт меньше трёх строк? Валяйте, покажите.

Ява, самая натуральная. Судя по докам, многопоточность там вырезана из самой виртуальной машины, той самой, что запускается у Гугла не серверах, а не в распространяемом бесплатно SDK. В SDK, скорее всего, используется policy.

> И ваапще, No Cl, make Clojure

Кожура CAN INTO futures?

> Кроме лиспотролля с баттхёртом от того, что быдлоЖаба и быдлоПлюсы уделали его кумира одной левой.

Наш рукопашный бой!..
Земля тряслась — как наши груди,
Смешались в кучу кони, люди,
И залпы тысячи орудий
Слились в протяжный вой… (c)

> Ява, самая натуральная.

А апплеты не имеют по умолчанию доступа к файловой системе и сетевым ресурсам. Что теперь, в Java файловые и сетевые операции работают везде по-разному? Демагогии не надо.

Из кложуры можно юзать все жабские либы, future в том числе.

> Из кложуры можно юзать все жабские либы, future в том числе.

Так и запишем: Кожура без батареек JVM — беспомощный кусок говна.

> Потому что библиотечного решения, удовлетворяющего требованиям

ТСа (таймауты, пулинг, переносимость)

Проблемы были замечены с возможность запуска под ECL. Что к вашим измышлениям отношения не имеет. Ну есть на есть какая-то реализация CL, под которую практически невозможно ничего загрузить, и что с того?

Так и запишем: жабa без батареек JVM — беспомощный кусок говна.

;;; fair fix

Чувак, любой язык без стандартной либы и конкретной имплементации (ну или спеки на эту имплементацию) представляет собой лишь немного большее, чем ebnf, записанное на бумажке.

Точно. Пора снимать розовые очки и перестать надрачивать на бесполезные (ну ладно, почти бесполезные) макросы.

А если серьезно, господа лисперы, ответьте мне на вопрос. Почему в вашем Common Lisp такая базовая вещь как потоки (threads) не включена в стандарт?

Потому что CL - это суть середина 80-х, когда не каждая популярная на то время операционная система эти треды поддерживала. Глупо в стандарт языка закладывать то, что не существует.

А на вашем лиспе приходится городить костыли под каждую имплементацию. Для XXI века это позор.

Ладно бы чё толкового вместо йавы сказал, а то позор во языцех толкаешь.

Как она может «следить за таймаутом?»

Оберни операцию в with-timeout из bordeaux-threads.

Ладно бы чё толкового вместо йавы сказал, а то позор во языцех толкаешь.

А ты замени жаву на скалу или кложур. Зри в суть. А суть это jvm. Не путайте платформу и один из ее языков.

>Как предлагается поступать в случае, если операция сообщает о своём завершении вызовом callback'а, а в случае подвисания не сообщает никак?

Также как и с future, дело в том что вызвав cancel у future вообще то ничего не добъешься, кроме interruptexception, который (вуаля) при IO зачастую игнорируется, и все, то бишь future перейдет в состояние «отменен»,

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

_________

//wfrr

это решается в месте вызова, а не индусским блокированием всех потоков на время, посмотреть «а не отвисли наш шкодинг»?

_________

//wfrr

> Врешь. В Google App Engine Java нет многопоточности.

Есть начиная с 1.4.3

>IO зачастую игнорируется

а еще большинство быдлокодеров его нещадно давят в малолетнем возрасте, отчего прервать выполнение Future ты собственно не сможешь извне, так что его использование еще и опасно 8)

_________

//wfrr

а не индусским блокированием всех потоков на время

Ничего не понял что ты там написал. Но я имел в виду такое решение: перед неблокирующим вызовом добавляется таймаут на последующую операцию. Неблокирующие либы обычно имеют такую фичу, таймаут. На каждом цикле ioloop проверяется не истекло ли время для какого-то таймаута. Так вот если истекло, то выполняется колбек. В нашем случае колбек должен попытаться закрыть соединение с которым выполняется блокирующий вызов и вызвать error_callback c ошибкой таймаут.

>. Но я имел в виду такое решение: перед неблокирующим вызовом добавляется таймаут на последующую операцию. Неблокирующие либы обычно имеют такую фичу, таймаут.

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

В нашем случае колбек должен попытаться закрыть соединение с которым выполняется блокирующий вызов и вызвать error_callback c ошибкой таймаут.

В нашем случае, вообщето мы не знаем какойто «там» в future вызов, future нас от этого абстрагирует, и вообще концепция future не поразумевает «закрытия» соединения, ибо future ни с к какими соединениям не свазяна.

Очевидно, что если мы заменяем future коллбеком, то тянуть в обсуждение некие «соединения» некорректно.

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

_________

//wfrr

В кложуре с многопоточностью все очень хорошо, из коробки (без левых библиотек) есть и futures и actors и STM, все оттестированное и работающее

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

При чем здесь блокирующие вызовы? Таймауты всем нужны. И в неблокирующих либах они тоже есть. Правда, они имеют в себе изъян. Таймауты проверяются всегда на следующей итерации цикла. Если на текущей запустить что-то тяжелое для cpu и долгое, то таймауты конечно сработают, но не раньше, чем эта тяжелая операция завершится.

В нашем случае, вообщето мы не знаем какойто «там» в future вызов, future нас от этого абстрагирует, и вообще концепция future не поразумевает «закрытия» соединения, ибо future ни с к какими соединениям не свазяна.

4.2

Future - обычно всего лишь интерфейс. Что делает метод cancel зависит от реализации. Если мы работаем с неблокирующим http-клиентом, то метод cancel у Future, возвращаемого этим клиентом таки закрывает соединение. Не веришь - посмотри в исходники ning async-http-client.

> В Java всё делается тем единственным способом, который диктует тебе дядя. А Лисп предоставляет неограниченные возможности.

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

> Потому что CL - это суть середина 80-х

А С++ - начало 80-х. Но сегодня в нём есть portable threads, а в CL - нет. Потому что C++ развивается, а CL - нет. Потому что С++ нужен человечеству, а CL остался на свалке истории.

> В кложуре с многопоточностью все очень хорошо, из коробки... все оттестированное и работающее

Юноша бледный со взором горящим.

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

А почему бы не послать дядю, и не начать диктовать себе самому?

> выполнение Future

выполнение Future

выполнение Future

Вы уверены, что вообще понимаете Java Concurrency Framework? У меня вот такой уверенности на Ваш счет нет…

Потому что С++ нужен человечеству, а CL остался на свалке истории.

(зевнул) што вы говорите?..

> Есть начиная с 1.4.3

Не думал, что maxcom читает такие треды :)

Имеются в виду Concurrent Requests?

Потому что это была шутка (как водится, с долей шутки). А у тебя, анонимный соратник, отсутствует чувство юмора.

>> Потому что С++ нужен человечеству, а CL остался на свалке истории.

(зевнул) што вы говорите?..

Что не так?