Параллельные сеансы в Дьялог АПЛ
Хотя бы один из однобуквенных языков q) имеет средство межпроцессного взаимодействия, своего рода параллельное выполнение более длительных процессов на нескольких компьютерах. Эти сеансы могут быть на одном компьютере или на сервере на другом континенте.
С q я просто запустил бы сервер для прослушивания определенного порта, что-то вроде q -p 8510, затем получите доступ к нему из другого сеанса q или другого программного обеспечения. Впечатляюще просто.
Я помню, в очень далеком прошлом, используя систему APL мэйнфреймов с Shared Variables где я мог бы поделиться переменной с другим пользователем. Это могло быть IBM APL.SV, Я не думал об этом в то время, но сегодня, десятилетия спустя, Shared Variables звучит как основа для параллельных сессий. Поделитесь переменной с другим компьютером.
Как мог или я мог бы сделать это сегодня с Dyalog APL или любым другим APL, где я мог
вызвать сеанс APL на другом физическом компьютере
отправить команду или выражение
получить результат
потенциально сделать это параллельно на многих других компьютерах
4 ответа
На самом деле, "старомодные" общие переменные все еще поддерживаются в Dyalog APL под Microsoft Windows по протоколу DDE, но они считаются устаревшими.
Последние версии Dyalog APL поддерживают параллельное или асинхронное выполнение через изоляты, которые являются отдельными процессами, которые отображаются как расширения активной рабочей области. Любое выражение, выполненное внутри изолята, немедленно возвращает будущее. Фьючерсы могут передаваться в качестве аргументов функциям и управляться структурными примитивами без блокировки; если они передаются в примитивную функцию, которая должна знать значение, они будут автоматически блокироваться до тех пор, пока не будет завершено вычисление результата.
Документация по фьючерсам и изолятам находится в Интернете, и в Интернете есть множество видео - например, здесь обсуждается, как они были представлены на Dyalog'14:
Параллельное программирование с Dyalog 14.0 на YouTube
В версии 17.0 мы будем включать поддержку класса APLSSH, что упростит запуск изолятов на удаленных машинах.
Наконец, если вы хотите обмениваться данными между процессами APL, которые уже запущены, библиотека TCP "Conga" (которая также включена в стандартную установку Dyalog) позволяет передавать массивы APL между процессами с использованием TCP/IP, даже если процессы работает на разных машинах архитектуры. Документация для Conga также онлайн.
Да, но VSVO происходит из-за того, что IP-адреса обычно не использовались (или даже не присутствовали). Левый аргумент VSVO - это "идентификатор процессора", концепция, похожая на дескрипторы файлов.
GNU APL следует за IBM APL2, за исключением того, что APL2 позволяет отображать идентификаторы локальных процессоров на идентификаторы удаленных процессоров и IP-адреса. Это отображение (в APL2) предоставляется как внешний файл конфигурации, и поддержка этого файла конфигурации является отсутствующим битом в GNU APL.
В GNU APL VSVO был предусмотрен только для некоторой обратной совместимости с IBM APL2, поэтому расширение его синтаксиса не имеет особого смысла. Для новых приложений APL намного проще использовать соединения UDP или TCP между процессами напрямую, и IOFIO предоставляет все, что для этого необходимо.
Если вы хотите сделать это старомодным способом (и, поверьте мне, нет), то вот пример того, как это сделать (в принципе):
http://svn.savannah.gnu.org/viewvc/apl/trunk/src/testcases/APnnn.tc?view=log
Посмотрите все файлы APnnn*. В GNU APL пример работает только с двумя рабочими пространствами APL, работающими на одной машине, но с IBM APL2 они могут находиться на разных машинах. В случае IBM потребуется дополнительная конфигурация для идентификаторов процессоров на удаленных машинах, поэтому пример нужно немного адаптировать.