Каков наилучший подход erlang к возможности идентифицировать идентификатор процесса по его идентификатору процесса?

Когда я занимаюсь отладкой, я обычно просматриваю около 5000 процессов, каждый из которых может быть одним из примерно 100 серверов поколения _, fsms и т. д. Если я хочу знать, ЧТО такое процесс erlang, я могу сделать:

process_info(pid(0,1,0), initial_call).

И получить результат вида:

{initial_call,{proc_lib,init_p,5}}

... что почти бесполезно.

Совсем недавно я натолкнулся на идею (приготовьтесь )зарегистрировать каждый процесс с именем, которое говорило бы мне, КОГО этот процесс представляет. Например, player _1150 — это процесс player, который представляет игрока 1150. Да, в конечном итоге я создаю пару миллионов атомов в течение недели -. (И я хотел бы услышать комментарии о недостатках увеличения предела до 10 000 000 атомов, когда моя система работает с неиспользуемыми около 8 ГБ реальной памяти, если таковые имеются. )Это означало, что я мог на консоли действующей системы запрашивать у всех процессов длину их очереди сообщений, находить основных нарушителей, затем проверять, были ли эти процессы зарегистрированы, и распечатывать атом, в котором они находились. зарегистрирован с.

У меня возникла загвоздка с этим :Я перемещаю процессы с одного узла на другой. Теперь процесс игрока может иметь 3 разных имени; player _1158, player _1158 _устарели, player _1158 _замена. И я должен быть абсолютно уверен, что я регистрирую и отменяю регистрацию этих имен с точным временем, чтобы убедиться, что процесс всегда назван и что соответствующие имена всегда существуют, И что я не пытаюсь зарегистрировать имя, которое уже принадлежит умирающему процессу.. Есть некоторый резерв, так как он используется только для консольной отладки работающей системы. Тем не менее,в тот момент, когда я начал чувствовать, что этот механизм влияет на то, как я разрабатываю систему (ту, которая перемещает процессы вокруг ), я почувствовал, что пришло время заняться чем-то другим.

У меня сейчас две идеи на столе. Таблицы ets, которые связывают идентификаторы процессов с их описанием :

ets:insert(self(), {player, 1158}).

. Мне это не очень нравится, потому что мне приходится вручную поддерживать чистоту столов. Когда игрок выходит (или падает ), кто-то отвечает за то, чтобы его данные были удалены из таблицы ets.

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

Я понимаю, что ни одно из этих решений не является функционально чистым, но, учитывая, что сама система никогда, НИКОГДА не является потребителем этих данных, меня это не слишком беспокоит. Мне нужны определенные инструменты отладки, чтобы работать быстро и легко, поэтому описанное поведение не подлежит обсуждению. Существуют ли какие-либо убедительные аргументы в пользу (того или иного пути, кроме академического «не используйте_, это зло" консервы фигня? )Буду рад услышать другие предложения и их обоснования.