LINUX.ORG.RU

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


0

2

Подскажите, есть ли для Common Lisp аналог Future и Executor из Java? Или какой-нибудь похожий метод. Нужно запускать асинхронное выполнение функций, и получать их результат в другое время, из другой функции и из другого потока. Обязательно чтобы был таймаут, аналогично Future.get(timeout, unit). Желательно чтобы задачи распределялись на thread pool, то есть не создавать новый thread на каждый новый вызов, потому что это неэффективно. Мне кажется задача должна хорошо уложиться в функциональную парадигму Лиспа. Но ничего готового не нашёл...

Ответ на: комментарий от Ignatik

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

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

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

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

_________

//wfrr

anonymous
()
Ответ на: комментарий от anonymous

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

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

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


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

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


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

Ignatik
() автор топика
Ответ на: комментарий от baverman

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

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

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

> не поддерживает 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

anonymous
()
Ответ на: комментарий от Ignatik

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

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

archimag ★★★
()
Ответ на: комментарий от Ignatik

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

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

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

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

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

_________

//wfrr

anonymous
()
Ответ на: комментарий от baverman

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

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

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

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

archimag ★★★
()
Ответ на: комментарий от Ignatik

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

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

baverman ★★★
()
Ответ на: комментарий от anonymous

> 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

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

Что не так?

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

baverman ★★★
()
Ответ на: комментарий от anonymous

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

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

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

Ignatik
() автор топика
Ответ на: комментарий от archimag

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

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

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

Что не так?

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

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

SBCL - Common Lisp.

ECL - Common Lisp.

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

tailgunner ★★★★★
()

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

Ignatik
() автор топика
Ответ на: комментарий от Ignatik

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

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


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

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


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

archimag ★★★
()

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

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

anonymous
()
Ответ на: комментарий от baverman

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

dave ★★★★★
()
Ответ на: комментарий от archimag

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

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

Ignatik
() автор топика
Ответ на: комментарий от anonymous

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

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

Ignatik
() автор топика
Ответ на: комментарий от anonymous

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

dizza ★★★★★
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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


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

anonymous
()
Ответ на: комментарий от Ignatik

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

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

[i]// FIXED[/i]

anonymous
()
Ответ на: комментарий от Ignatik

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

dave ★★★★★
()
Ответ на: комментарий от anonymous

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

dizza ★★★★★
()
Ответ на: комментарий от dave

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.