Как изменялось receive и почему

Ранний синтаксис Erlang пришел прямо из Пролога. Erlang был реализован непосредственно в Prolog с использованием тщательного выбора инфиксных операторов. На рисунке 4, адаптированном из [2], показан фрагмент программы телефонии 1988 года и соответствующая программа, которая будет написана сегодня. Обратите внимание, что есть два основных изменения:

Во-первых, в примере 1988 года шаблоны были представлены терминами Пролога, поэтому digit(D) представляет шаблон. В современном Erlang тот же синтаксис представляет вызов функции, и шаблон пишется { digit, D}.

Второе изменение связано с тем, как были написаны схемы приема сообщений. Синтаксис:

Proc! Message

означает отправить сообщение, пока:

receive {

  Proc1? Mess1 =>

        Actions1;

  Proc2? Mess2 =>

        Actions2;

       ...

} 

означает попытаться получить сообщение Mess1 от Proc1, в этом случае выполнить Actions1; в противном случае попробуйте получить Mess2 от Proc2 и т. д. Синтаксис Proc? Message казалось сначала очевидным выбором для обозначения приема сообщения и было выбрано главным образом по соображениям симметрии. Ведь если А! B означает отправить сообщение, то обязательно A? B должно означать получение сообщения.

Проблема в том, что нет способа скрыть личность отправителя сообщения. Если процесс A отправляет сообщение B, то получает сообщение с шаблоном формы P? M, где P и M - несвязанные переменные, всегда приводит к тому, что идентичность A связана с P. Позже мы решили, что это плохая идея, и что отправитель должен иметь возможность выбирать, раскрывать ли он свою идентичность процессу, который он отправляет сообщение Таким образом, если A хочет отправить сообщение M процессу B и раскрыть его личность, мы могли бы написать код, который отправляет сообщение как B! {Self (), M}, или, если он не хотел раскрывать свою личность, мы мог написать просто B! М. Выбор не автоматический, но решается программистом.

Это приводит к общепринятому языку программирования для написания таких процедур, как то, что отправитель должен всегда включать свой собственный Pid (идентификатор процесса) (Pid для ответа) в сообщение, отправляемое на сервер. То, как мы делаем это сегодня, показано на рисунке 9.

Обратите внимание, что мы также можем использовать тот факт, что процессы не раскрывают свою идентичность, чтобы написать безопасный код и подделать идентичность процесса. Если сообщение отправлено процессу, и это сообщение не содержит информации об отправителе, то получатель сообщения не сможет узнать, от кого оно было отправлено. Это может быть использовано в качестве основы для написания безопасного кода на Erlang.

Наконец, поддельные сообщения Pids могут быть использованы для делегирования обязанностей. Например, большая часть кода в подсистеме IO написана с помощью сообщений {Request, ReplyTo, ReplyAs}, где Request - это термин, запрашивающий какую-либо услугу IO. ReplyTo и ReplyAs - это Pids. Когда завершающий процесс выполнения операции завершил свою работу, он отправляет сообщение, оценивая ReplyTo! {ReplyAs, Result}. Если это затем используется в коде в идиоме программирования RPC на рис. 5, этот код фактически подделывает Pid процесса ответа.

Теперь смысл всего этого аргумента, который может показаться довольно неясным, заключается в том, что казалось бы незначительное изменение поверхностного синтаксиса, то есть нарушение симметрии между A! B и A? B, имеет глубокие последствия для безопасности и того, как мы программируем. И это также объясняет часовые дискуссии о точном размещении запятых и, что более важно, что они означают (Все разработчики языка, несомненно, знакомы с явлением, что пользователи с удовольствием обсуждают синтаксис в течение нескольких часов, но таинственным образом исчезают, когда разработчик языка хочет поговорить о том, что на самом деле означает новый синтаксис).

4.6 Беспрерывная работа  ... годами

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

В настоящее время нас интересовало только подключение обычных последовательных компьютеров без разделяемой памяти. Наша идея состояла в том, чтобы подключить стандартное оборудование через сокеты TCP/IP и запустить кластер машин за корпоративным брандмауэром. Нас не интересовала безопасность, так как мы представляли все наши компьютеры, работающие в частной сети без внешнего доступа. Эта архитектура привела к форме безопасности «все или ничего», которая делает распределенный Erlang пригодным для программирования приложений кластера, работающих в частной сети, но не подходящим для запуска распределенных приложений, где задействованы различные степени доверия.

1990

В 1990 году Клас (Клаке) Викстрем присоединился к Лаборатории - Клаке работал в другой группе в Эллемтеле, и как только ему стало любопытно, что мы делаем, мы не смогли его удержать. Клаке присоединился, и группа Erlang расширилась до четырех.

ISS'90

Одним из самых ярких моментов 1990 года стал Международный выставочный симпозиум ISS’90 (Стокгольм). ISS'90 был первым случаем, когда мы активно пытались продать Erlang. Мы изготовили множество брошюр, наняли стойку на торговой ярмарке и побежали - круглосуточные демонстрации системы Erlang. Маркетинговые материалы этого периода показаны на рисунках 6 и 7. На данный момент нашей целью было попытаться распространить Erlang на ряд компаний в телекоммуникационном секторе. Это было сочтено стратегически важным - руководство считало, что если мы будем работать вместе с нашими конкурентами над исследовательскими проблемами, представляющими взаимный интерес, это приведет к успешным коммерческим альянсам. У Ericsson никогда не было цели заработать большие суммы денег, продавая Erlang, и у нее не было организации, способной поддержать эту цель, но она была заинтересована в поддержании высокого технического профиля и взаимодействии с инженерами-единомышленниками в других компаниях.

1991

В 1991 году Клаке начал работу по добавлению дистрибутива в Erlang, чего давно ждали. К настоящему времени Erlang распространился на 30 сайтов. Механизмы этого распространения неясны, но в основном это происходит из уст в уста. Часто мы получали письма, запрашивающие информацию о системе, и понятия не имели, где они узнали об этом. Один вероятный механизм был через списки рассылки usenet, где мы часто публиковали на comp.lang.functional. После того, как мы создали прецедент выпуска системы для Bellcore, доставить систему последующим пользователям стало намного проще. Мы только что повторили то, что сделали для Bellcore. В конце концов, после того, как мы выпустили систему для дюжины или около того пользователей, наши менеджеры и юристы устали от нашего приставания и позволили нам выпустить систему кому бы мы ни хотели, при условии, что они подписали соглашение о неразглашении.

Кроме того, Ericsson Business Communications перенесла Erlang на компьютер FORCE и операционную систему реального времени VxWorks; это были наши первые шаги к встроенной системе. Этот порт был обусловлен требованиями к продукту, поскольку мобильный сервер в то время работал на VxWorks. Мы также портировали Erlang практически на все операционные системы, к которым у нас был доступ. Целью этих портов было сделать язык доступным для большого числа пользователей, а также улучшить качество самой системы Erlang. Каждый раз, когда мы переносили систему на новую ОС, мы обнаруживали новые ошибки, которые появлялись таинственными способами, поэтому перенос на большое количество разных ОС значительно улучшал качество самой системы во время выполнения.

1992

В 1992 году мы получили разрешение на публикацию книги, и было принято решение о коммерциализации Erlang. Контракт был подписан с Prentice Halland, первая книга об Erlangе, появившаяся в книжных магазинах в мае 1993 года. Даже это решение требовало немалых усилий со стороны руководства - это определенно было не так, как Ericsson делала ранее; более ранние языки, такие как PLEX, были внутренними разработками. Первой реакцией менеджмента в то время было «если мы сделали что-то хорошее, мы должны молчать об этом», что совершенно противоположно сегодняшней реакции на движение с открытым исходным кодом. Решение опубликовать книгу об Erlangе ознаменовало изменение отношения внутри Ericsson. Последним языком, разработанным Ericsson для программирования переключателей, был PLEX. PLEX был проприетарным: очень мало людей за пределами Ericsson знали что-либо о PLEX, и в университетах не было курсов PLEX и не было внешнего рынка для программ PLEX или программистов. Эта ситуация имела свои преимущества и недостатки. Основным преимуществом было то, что PLEX дала Ericsson коммерческое преимущество перед конкурентами, которые, как предполагалось, имели более слабые технологии. Недостатки были связаны с изоляцией. Поскольку никто не использовал PLEX, Ericsson пришлось поддерживать все, что связано с PLEX: писать компиляторы, проводить курсы, все.

AT & T, однако, принял другой подход с C и C ++. Здесь бремя поддержки этих языков было разделено всем сообществом, и изоляции удалось избежать. Поэтому решение опубликовать книгу об Erlangе и быть достаточно открытым о том, что мы сделали, заключалось в том, чтобы избежать изоляции и следовать пути AT & T / C, а не пути Ericsson / PLEX. Также в 1992 году мы портировали Erlang на MS-DOS, Mac, QNX и VxWorks. Проект Mobility Server, основанный на успешном исследовании ACS / Dunder, был начат примерно через два года после завершения проекта ACS / Dunder. Почему проект мобильности сервера потерял импульс, неясно. Но часто так и происходит: за периодами быстрого роста следуют необъяснимые периоды, когда кажется, что ничего особенного не происходит. Я подозреваю, что это периоды консолидации. При быстром росте углы обрезаются, и все делается неправильно. В периоды между ростом система полируется. Недостатки кода удаляются и переделываются. На поверхности мало что происходит, но под поверхностью система перестраивается.

Turbo Erlang

В 1993 году система Turbo Erlang начала работать. Создателем Турбо Erlang был Богумил (Богдан) Хаусман, который присоединился к лаборатории из SICS (Шведский институт компьютерных наук). По непонятным юридическим причинам название Turbo Erlang было изменено на BEAM (абстрактная машина Богдана Erlang). Компилятор BEAM скомпилировал программы Erlang в инструкции BEAM.

Инструкции BEAM могут быть макроразвернуты в C и впоследствии скомпилированы или преобразованы в инструкции для 32-битного интерпретатора многопоточного кода. Программы BEAM, скомпилированные для C, работали примерно в десять раз быстрее, чем программы с интерпретацией JAM, а интерпретируемый код BEAM работал более чем в три раза быстрее, чем программы JAM.

К сожалению, программы, скомпилированные BEAM-to-C, увеличили объемы кода, поэтому было невозможно полностью скомпилировать большие приложения в C-код. Некоторое время мы решили эту проблему, рекомендовав гибридный подход. Небольшое количество критичных для производительности модулей будет скомпилировано в C-код, тогда как другие будут интерпретироваться.

В наборе команд BEAM использовались 32-битные инструкции фиксированной длины и потоковый интерпретатор по сравнению с JAM, который имел инструкции переменной длины и являлся интерпретатором с байтовым кодом. Интерпретатор многопоточного кода BEAM был намного более эффективным, чем интерпретатор JAM, и не страдал от расширения кода, связанного с компиляцией в Си. В конечном итоге набор инструкций BEAM и многопоточный интерпретатор были приняты, а JAM прекратил работу.

Я должен поподробнее рассказать о размере кода. Одной из главных проблем во многих продуктах был большой объем объектного кода. Телефонные коммутаторы имеют миллионы строк кода. Например, текущее программное обеспечение для AXD301 содержит пару миллионов строк Erlang и большое количество кода на языке С. В середине 90-х годов, когда были разработаны эти продукты, объем встроенной памяти составлял около 256 Мбайт. Сегодня у нас есть память в Гбайтах, поэтому проблема объема объектного кода практически исчезла, но в середине 90-х это стало серьезной проблемой. Опасения относительно размера памяти объектного кода лежат в основе многих решений, принимаемых в наборах команд и компиляторах JAM и BEAM.

Распределенный Erlang

Другое крупное техническое событие в 1993 году было посвящено распределенному Erlang. Распределение всегда планировалось, но у нас никогда не было времени для его реализации. В то время все наши продукты работали на однопроцессорных системах, и поэтому не было необходимости реализовывать дистрибуцию. Распределение было добавлено как часть нашей серии текущих экспериментов, и только в 1995 году и AXD301 это распределение использовалось в продукте.

Добавляя дистрибутив, Klacke применил несколько новых приемов реализации. Особенно заслуживает упоминания кэш связи между атомами, описанный в [30], который работал следующим образом:

Представьте, что у нас есть распределенная система, в которой узлы на разных хостах хотят посылать атомы Erlang друг другу. В идеале мы могли бы представить некоторую глобальную хеш-таблицу, и вместо отправки текстового представления атома, мы просто отправили бы хэшированное значение атома. К сожалению, поддерживать согласованность такой хеш-таблицы - сложная проблема. Вместо этого мы поддерживаем две синхронизированные хеш-таблицы, каждая из которых содержит 256 записей. Чтобы отправить атом, мы хэшировали атом в один байт и затем искали это в локальной хеш-таблице. Если значение было в хеш-таблице, то все, что нам нужно было сделать, это отправить на удаленную машину однобайтовый хеш-индекс, поэтому отправка атома между машинами включала отправку одного байта. Если значение не было в хеш-таблице, мы сделали недействительным значение в кеше и отправили текстовое представление атома. Используя эту стратегию, Клаке обнаружил, что 45% всех объектов, отправляемых между узлами в распределенной системе Erlang, были атомами и что частота попаданий в кэш атома составляла около 95%. Этот простой трюк делает вызовы удаленных процедур Erlang более сложными для сложных структур данных, чем, например, механизм SunOS RPC.

При построении распределенного Erlang нам теперь пришлось учитывать такие проблемы, как отбрасывание сообщений и удаленные сбои. Erlang не гарантирует доставку сообщений, но он предоставляет более слабые гарантии при упорядочении сообщений и при уведомлении об ошибках. По мнению Erlang, передача сообщений ненадежна, поэтому отправка сообщения не гарантирует, что оно будет получено. Даже если сообщение будет получено, нет никаких гарантий, что сообщение будет выполнено так, как вы предполагали. Поэтому мы придерживаемся мнения, что если вам требуется подтверждение получения сообщения, получатель должен отправить ответное сообщение, и вам придется ждать этого сообщения. Если вы не получите это ответное сообщение, вы не будете знать, что произошло. В дополнение к этому существует механизм связи, который позволяет одному процессу связываться с другим. Цель ссылки - предоставить механизм мониторинга ошибок. Если процесс, с которым вы связаны, умирает, вам будет отправлен сигнал об ошибке, который можно преобразовать в сообщение об ошибке.

Если вы связаны с процессом и отправляете поток сообщений этому процессу, можно предположить, что никакие сообщения не будут отброшены, что сообщения не повреждены и что сообщения будут доставлены этому процессу в порядке их отправки. или что произошла ошибка, и вам будет отправлен сигнал об ошибке. Все это предполагает, что TCP/IP сам по себе надежен, поэтому, если вы считаете, что TCP/IP надежен, передача сообщений между связанными процессами будет надежной.

Распространение Erlang

В апреле 1993 года была основана новая компания под названием Erlang Systems AB, которая принадлежала Ericsson Programatic. Цель состояла в том, чтобы выйти на рынок и продавать Erlang. Кроме того, Erlang Systems должна была взять на себя ответственность за обучение, консультирование и производство высококачественной документации.

Erlang Systems также предоставила основной источник работы для «Упсальских мальчиков». Это были бывшие студенты-информатики из Упсальского университета, которые завершили магистерскую работу в рамках проекта Erlang. Многие из этих студентов начали свою карьеру в Erlang Systems и были впоследствии наняты в проекты Ericsson в качестве внутренних консультантов. Это оказалось ценным способом «запустить» проект с молодыми и увлеченными аспирантами, которые были опытными в Erlangе.

Еще одним запоминающимся событием 1993 года стал показ Erlang на выставке, состоявшейся в октябре в Стокгольме. Основным демонстратором на дисплее была программа, которая одновременно контролировала небольшую телефонную станцию ​ ​ (MD110 LIM (модуль линейного интерфейса)) и модельный поезд. На рисунке 8 показано, как Роберт Вирдинг усердно работает в лаборатории, программируя модель поезда. Справа от компьютера за комплектом поезда находится МД100 LIM. После ярмарки в течение нескольких лет мы использовали набор поездов для упражнений по программированию на курсах Erlang, пока оно не было сломано из-за чрезмерного использования. Хотя управляющее программное обеспечение было отказоустойчивым, аппаратное обеспечение было гораздо менее надежным, и мы столкнулись с небольшими механическими проблемами.

Крах AX-N

В декабре 1995 года крупный проект в Эллемтеле под названием AX-N потерпел крах. Это было единственное самое важное событие в истории Erlang. Без краха AX-N Erlang все равно остался бы лабораторным экспериментом, и попытка превратить его в продукт коммерческого качества не состоялась бы. Разница заключается в том, что для создания высококачественной документации, а также для создания и тестирования обширных библиотек требуется много тысяч часов работы. AX-N был проектом, нацеленным на разработку нового поколения коммутационных продуктов, в конечном счете, для замены системы AXE10. В рамках проекта AX-N была разработана новая аппаратная платформа и системное программное обеспечение, разработанное на C ++.

После серии кризисных встреч проект был реорганизован и возобновлен. На этот раз языком программирования был Erlang, а оборудование из проекта AX-N было спасено, чтобы начать производство нового переключателя ATM (Асинхронный режим передачи), который будет называться AXD. Этот новый проект должен был стать самым большим из когда-либо созданных Erlang-проектов с более чем 60 программистами Erlang. В начале проекта AXD за всю систему Erlang отвечали полдюжины человек из Лаборатории. Это число было сочтено неадекватным для удовлетворения потребностей крупного проекта разработки, и поэтому были немедленно приняты планы по созданию подразделения продукта, называемого OTP, для официальной поддержки системы Erlang. В это время весь внешний маркетинг Erlang был остановлен, поскольку все доступные «ресурсы» теперь должны быть направлены на внутреннюю разработку продукта.

OTP расшифровывается как «Open Telecom Platform» и является как названием дистрибутива программного обеспечения Erlang, так и названием подразделения продуктов Ericsson, что может несколько запутать. Единица OTP началась в Лаборатории, но в 1997 году была сформирована как новая единица продукта за пределами Лаборатории. С 1997 года подразделение OTP отвечает за распространение Erlang.

BOS – OTP и поведения

Наряду с развитием языка Erlang вопрос о библиотеках и промежуточном программном обеспечении всегда был важным. Erlang - это просто язык программирования, и для построения полной системы требуется нечто большее, чем просто язык программирования. Для создания любого значительного объема программного обеспечения вам нужен не только язык программирования, но и значительный набор библиотек и какая-то операционная система, на которой можно все выполнять. Вам также нужна философия программирования - так как вы не можете создать большой объем программного обеспечения на специальной основе без каких-либо руководящих принципов.

Общее название для Erlang, все библиотеки Erlang, система времени исполнения Erlang и описания способа работы Erlang - это система OTP. Система OTP содержит:

· Библиотеки кода Erlang.

· Шаблоны проектирования для создания общих приложений.

· Документация.

· Курсы.

· Обучающие материалы.

Библиотеки организованы и описаны обычным способом. У них также есть довольно обычная семантика. Что происходит в сообщении двух разных процессов? Ответ: побочные эффекты, подобные этому, разрешены. Erlang - это не строгий функциональный язык без побочных эффектов, а параллельный. Если два разных процесса получают Pid в файле, оба могут отправлять сообщения в файловый процесс. Это зависит от логики приложения, чтобы предотвратить это.

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

В этом случае проблем из-за совместного использования ссылки можно избежать.

На практике эта такого рода проблемы редки.

Шаблоны проектирования (так называемые модели поведения) являются результатом многолетнего опыта создания отказоустойчивых систем. Они обычно используются для создания таких вещей, как модели клиент-сервер, системы обработки событий и т. д. Поведение в Erlang можно рассматривать как параметризуемые параллельные процессы высшего порядка. Они представляют собой расширение обычных функций высшего порядка (таких как map, fold и т. Д.) в параллельную область.

На дизайн поведения OTP сильно повлияли две предыдущие попытки. Первой была система под названием BOS (Basic Operating System). BOS была написана для операционной системы приложений в Bollmora в Erlangе специально для проекта Mobility Server. BOS в целом решил ряд проблем, в частности, как создать общий сервер и как создать общий дочерний элемент супервизора ошибок. Большая часть этого была сделана Питером Хегфельдтом. Вторым источником вдохновения был общий сервер, созданный Klacke.

Когда начался проект OTP, я отвечал за общую технологию проекта и за разработку нового набора поведений, которые можно было бы использовать для отказоустойчивых систем. Мартин Бьёрклунд и Магнус Фрёберг были вовлечены в развитие поведения. На рисунке 9 представлена ​ ​ упрощенная схема поведения клиент-сервер. Обратите внимание, что эта модель обеспечивает нормальную функциональность клиент-сервер и возможность горячей замены кода. Полный набор примеров можно найти в [7].

Код 9. Универсальная модель клиент-сервер с горячей заменой кода.

  

 

-module(server).

-export([start/2, call/2, change_code/2]).

   

start(Fun, Data) ->

  spawn(fun() -> server(Fun, Data) end).

   

call(Server, Args) ->

rpc(Server, {query, Args}}

     

change_code(Server, NewFunction) ->

   rpc(Server, {new_code, NewFunction}).

   

rpc(Server, Query) ->

Server! {self(), Query},

receive

{Server, Reply} -> Reply

end.

    

server(Fun, Data) ->

  receive

    {From, {query, Query}} ->

      {Reply, NewData} = Fun(Query, Data),

      From! {self(), Reply},

      server(Fun, NewData);

    {from, {swap_code, NewFunction} ->

      From! {self(), ack},

      server(Data, NewFunction)

end.

Другие изменения в языке

В период с 1989 по 1998 год, т. е. от существовавшей стабильной системы на основе JAM и до выпуска открытого исходного кода Erlang, в язык закрались некоторые изменения. Они могут быть классифицированы как серьезные или незначительные изменения. В этом контексте незначительное означает, что изменение может быть классифицировано как простое постепенное улучшение языка. Незначительные изменения все время предлагают себя и постепенно добавляются к языку без особых обсуждений. Незначительные изменения делают жизнь программиста намного проще, но не влияют на то, как мы думаем о самом процессе программирования. Они часто основаны на идеях в традиционных языках программирования, которые ассимилированы в Erlang. Были внесены следующие незначительные изменения:

· Записи.

· Макросы.

· Включение файлов.

· Инфиксная нотация для добавления и вычитания списка («++» и «--»).

Основные изменения описаны в следующих разделах.

⇐ Предыдущая123456Следующая ⇒

Поделиться: