Любое общение между процессами осуществляется через очередь сообщений. handle_call/cast/info — просто очень высокая надстройка над обыкновенным оператором "!", они все точно так же последовательно выхватываются из очереди. «Сразу два» просто-напросто не бывает :)
Другое дело, если проверка и изменение разнесены на два отдельных обращения к процессу. Тогда, конечно, кто-нибудь может вклиниться; но для этого надо соответствующим образом планировать интерфейс модуля.
Эти принципы прекрасно соблюдаются. Все модули, работающие со сложными структурами типа словарей и деревьев, не изменяют структуру, которую им дают на входе, а разбирают ее на куски и строят и возвращают совершенно новую.
Когда-то читал про интересную систему — по периметру комнаты расставляется множество колонок, на которые подаются такие сигналы, которые в одних точках комнаты в сумме дают тот звук, который там нужен, а в других дают ноль. Все в выигрыше — и у каждого своя музыка, и никому не надо в наушниках сидеть.
У меня сейчас только одна хоть сколько-нибудь жизнеспособная гипотеза — что кто-то по ошибке или незнанию прибил процесс. Случаи самопроизвольной смерти epmd, когда никто ничего не трогает, насколько я могу судить, еще не были зафиксированы.
(Мы сами к той системе, кстати, имеем только достаточно ограниченный удаленный доступ и знаем только то, что нам говорят и что видно по логам. Тут с расследованием не особо развернешься.)
Еще по синтаксису исключений.
Если нужно обернуть весь метод целиком, begin можно отбросить — получаем def f
...
rescue
...
end
То же самое относится и к классам: если нужно ловить исключения, например, из этой вашей метапрограммерской магии, можно написать class C
...
rescue
...
end
Можно воспользоваться тем, что каждая тройка RDF сама по себе может быть представлена как объект rdf:Statement со свойствами rdf:subject, rdf:object и rdf:predicate; но тогда, при наивном хранении, в три раза возрастает объем представления одной и той же информации, т.к. каждую тройку надо держать в расписанном виде. Если движок дает возможность хранить мета-факты в более компактном виде (ссылкой на ID тройки в таблице или еще как-нибудь), то вполне даже вариант.
Другое дело, если проверка и изменение разнесены на два отдельных обращения к процессу. Тогда, конечно, кто-нибудь может вклиниться; но для этого надо соответствующим образом планировать интерфейс модуля.
:runtime! syntax/2html.vim
fun(F, L) -> lists:map(F, L) end.> F = fun lists:map/2.#Fun<lists.map.2>
let fact n = let rec fact_helper n a = if n = 1 then a else fact_helper (n-1) (a*n) in fact_helper n 1 ;;У меня сейчас только одна хоть сколько-нибудь жизнеспособная гипотеза — что кто-то по ошибке или незнанию прибил процесс. Случаи самопроизвольной смерти epmd, когда никто ничего не трогает, насколько я могу судить, еще не были зафиксированы.
(Мы сами к той системе, кстати, имеем только достаточно ограниченный удаленный доступ и знаем только то, что нам говорят и что видно по логам. Тут с расследованием не особо развернешься.)
Вот прямо так по-русски и называются нодами? ;)
Слово «node» вообще-то именно как «узел» и переводится.
Ну-ка, ну-ка :)
Если нужно обернуть весь метод целиком, begin можно отбросить — получаем
def f...
rescue
...
end
То же самое относится и к классам: если нужно ловить исключения, например, из этой вашей метапрограммерской магии, можно написать
class C...
rescue
...
end
Еще есть вот такой полезный список тонкостей работы raise/rescue/ensure/else: www.davidflanagan.com/2007/03/ruby-exceptionhandling-quiz.html