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

вот это действительно тонко

В смысле? Разве это сложно с лисповыми ФПП и макросистемой? Наверняка должно же быть что-то

http://www.cliki.net/Eager%20Future2

available in quicklisp

фишка в том что Future суть костыль, даже для явы.

во первах он блокирует вызывающие get() поток

во вторых, он какбы плохо сочетается с концепцией отсутствия «побочных эффектов» выполнения функци (в данном случе метода run)

хотя да, если лисп не позволяет выразить решение задачи в функциональном стиле то придется тянуть костыли из явы.

_________

//wfrr

Очень хорошо. Про треды, м-м-м.

Хотя, может быть ты всё-таки не тролль и просто забыл указать каким CL пользуешься?

> http://www.cliki.net/Eager%20Future2

не поддерживает timeout, не поддерживает thread pool
но уже хоть что-то, спасибо

> фишка в том что Future суть костыль, даже для явы.

А что тогда не костыль?

во первах он блокирует вызывающие get() поток

А как вы себе это представляете по-другому? через callback? не вижу проблем.
Через select/poll семантику? так она там тоже есть

во вторых, он какбы плохо сочетается с концепцией отсутствия «побочных эффектов» выполнения функци (в данном случе метода run)

А что плохого в побочных эффектах? Мы же, в отличие от Haskell-истов, не д***чим на отсутствие сайд-эффектов и иммутабельные коллекции

> Хотя, может быть ты всё-таки не тролль и просто забыл указать каким CL пользуешься?

А причём тут это? Разве подобные вещи не должны быть implementation agnostic? SBCL, если что

> не поддерживает timeout

4.2

function select-timeout (timeout &rest futures) => future or nil

Given a timeout (in seconds) and a set of futures, returns either nil if no futures are ready to yield when timeout seconds have elapsed, or the first yieldable future otherwise.

не поддерживает thread pool

4.2

https://github.com/vsedach/Eager-Future2/blob/master/scheduler.lisp

> не поддерживает timeout, не поддерживает thread pool

Хм, да вроде поддерживает.

>А что тогда не костыль?

через callback? не вижу проблем.

Сам спросил сам ответил 8)

А что плохого в побочных эффектах?

В данном конкретном случае в явке ЕМНИП получается фееричная ситуация когда исключение бросается каждый раз при вызове get в случае выброса его из run, причем это весьма неожиданно 8) Потом ситуация с блокировками, которых при callback подходе можно избежать, и как следствие ситуацией отработки зависших задач, при future у тебя будет висеть два потока (или один будет периодически подвисать на таймаут), а при callback у тебя будет висеть только один. В яве добавляется фееричная невозможность остановить поток при некоторых операциях IO, да и если ты его остановил то IE получишь в двух местах, и шо с ним делать то? Хотя да, это не столько о побочных эффектах сколько о данном костыле.

_________

//wfrr

ну т.е. разрабатываю и отлаживаюсь в SBCL, а в production будет ECL, если знаете такой... Embeddable Common Lisp
не вижу причин, по которым оно должно не заработать в ECL

> не вижу причин, по которым оно должно не заработать в ECL

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

Разве подобные вещи не должны быть implementation agnostic?

Так то оно так, но ткни пальцем в каком CL стандарте написано про потоки? Поэтому реализация отдается на откуп конкретным лиспам под конкретной осью.

SBCL -> ECL

Жесть как она бывает.

> Given a timeout (in seconds) and a set of futures, returns either nil if no futures are ready to yield when timeout seconds have elapsed, or the first yieldable future otherwise.

Вы вообще читать умеете? это не тот timeout, что мне нужен
мне нужен таймаут на каждый конкретный yield

> Жесть как она бывает.

Что не так?

Что не так?

Обязательно поделись результатами.

ткните меня в то место, где написано что Eager Future2 не поддерживает ECL

> где написано что Eager Future2 не поддерживает ECL

В каких прекрасных местах вы до этого жили?

> Сам спросил сам ответил 8)

callback это конечно хорошо
но как тогда отрабатывать таймауты?
запускать ещё один поток, который будет отсчитывать таймаут и сигналить / выбрасывать исключение куда-то? и снимать его при успешном вызове коллбека?

и после этого кто-то имеет наглость называть Future костылём?

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

Вы вообще умеете отвечать по-существу, а не вопросом на вопрос?

Eager Future2 - реализация Future для Common Lisp.
SBCL - Common Lisp.
ECL - Common Lisp.
Точка.

Что не так?

> Eager Future2 - реализация Future для Common Lisp.

SBCL - Common Lisp.

ECL - Common Lisp.

Вероятно, тебе пытаются объяснить, что (допустимые) отклонения от стандарта CL в е SBCL и ECL таковы, что делают работу Eager Future2 на ECL сомнительной.

>но как тогда отрабатывать таймауты?

Какие таймауты если нет блокировки?

_________

//wfrr

> Подскажите, есть ли для Common Lisp аналог Future и Executor из Java?

Ты ничего не понял, Future в Лиспе не нужно, Лисп работает по-другому.

> Какие таймауты если нет блокировки?

Разжёвываю, для непонятливых. Необходимо запустить асинхронно некоторую операцию (обращение к внешней системе, например). Если операция не завершилась за 30 секунд - это нештатная ситуация, её надо обработать по-особому. Это называется таймаут. Как предлагается поступать в случае, если операция сообщает о своём завершении вызовом callback'а, а в случае подвисания не сообщает никак?

> Как предлагается поступать в случае, если операция сообщает

о своём завершении вызовом callback'а

Хм, передавать в callback ошибку?

а в случае подвисания не сообщает никак?

Пусть она сама за своим таймаутом следит, в чём проблема?

А если серьезно, господа лисперы, ответьте мне на вопрос. Почему в вашем Common Lisp такая базовая вещь как потоки (threads) не включена в стандарт? В стандарт много чего не включено, но все можно понять, кроме threads. Ведь именно поэтому общелисп НЕ МОЖЕТ В portable multitreading. А ведь так ненавидимая вами Java определяет унифицированный способ работы с потоками и примитивы синхронизации, которые будут работать гарантированно одинаково абсолютно везде, где есть Java. Хоть на HotSpot VM, хоть на JRockit, хоть на сраном быдлофоне с J2ME, хоть на менее сраном ведроидофоне.

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

> Ты ничего не понял, Future в Лиспе не нужно, Лисп работает по-другому.

Как именно - по-другому?

Мм.. Не знал, что у питона есть Future.

> Пусть она сама за своим таймаутом следит, в чём проблема?

Вы вообще имеете понятие о legacy-системах?
Запрос происходит к внешней системе. Исходного кода системы нет. Сетевые операции с этой системой имеют обыкновение не завершаться за 30 секунд. Как она может «следить за таймаутом?»

> Java определяет унифицированный способ работы с потоками

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

А что нужно? По идее кошерным является монада cont.

А если серьезно, господа цепепешники, ответьте мне на вопрос. Почему в вашем C++ такая базовая вещь как потоки (threads) не включена в стандарт? В стандарт много чего не включено, но все можно понять, кроме threads. Ведь именно поэтому C++ НЕ МОЖЕТ В portable multitreading. А ведь так ненавидимая вами Java определяет унифицированный способ работы с потоками и примитивы синхронизации, которые будут работать гарантированно одинаково абсолютно везде, где есть Java. Хоть на HotSpot VM, хоть на JRockit, хоть на сраном быдлофоне с J2ME, хоть на менее сраном ведроидофоне.

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

Какие таймауты если нет блокировки?

Такие, что бы не было на долго «заснувших» вызовов.

По существу ответить нечего? Один-ноль, слив засчитан.

Почему в вашем C++ такая базовая вещь как потоки (threads) не включена в стандарт?

Два-ноль. man std::thread

> А Лисп предоставляет неограниченные возможности...

...дёрнуть себе анус.

[i]// FIXED[/i]

> Как именно - по-другому?

Что за дурацкие вопросы? Разумеется, аппликативными функторами, монадическими трансформерами, анафорическими лямбдами, пандорическим захватом, параморфизмами, хистоморфизмами, алгеброй и коалгеброй Келвина Элгота наконец

> Два-ноль. man std::thread

Давай-ка, напиши мне портабельно средствами только C++, а я позапускаю на различных платформах/операционных системах.

> Давай-ка, напиши мне портабельно средствами только C++, а я позапускаю на различных платформах/операционных системах.

Ты дебил? std:: это и есть «средства C++».

уже все компиляторы C++ поддеживают это? на всех системах?

> Java определяет унифицированный способ работы с потоками и примитивы синхронизации, которые будут работать гарантированно одинаково абсолютно везде, где есть Java.

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

GCC и Intel, на x86 и x86_64, под Linux и Windows.

Этого мало?

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

Да кому она на фиг сдалась, эта кроссплотформенность? Для меня если софтина работает под linux i386 и linux x64, то она супер портабельная и переносимая, все остальное дрочерство на переносимость.

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

И что? Я тебе в любом Tomcat обрежу многопоточность через security policy.
Лисперы такие лисперы, любят подменять понятия. Речь шла о Java-платформах, а не о кастомных деплойментах и sandbox'ах. Я и твоему SBCL'ю подсуну заглушку вместо libpthread.so, назову это «Lisp App Engine», а потом буду вонять о том, что-де в лиспе нет многопоточности.

> Два-ноль. man std::thread

треды в стандарте не нужны.

Кстати, там и std::future есть. Тоже костыль?

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

> треды в стандарте не нужны.

Если чего-то нет в LISP'е, значит, оно не нужно? Знакомая пейсня, ага.