Pull to refresh

Comments 22

А почему использован std::map<>, а не unordered_map<>? Есть какие-то ограничения или просто «привычка»...?
На маленьких объемах данных std::map эффективнее. unordered_map начинает обгонять когда элементов оказывается от сотни и больше. Тут же не ожидается большого набора элементов.
> Следовательно, нам в C++ пришлось бы использовать не просто умные указатели, а некие специальные умные прокси-ссылки.

weak_ptr же
Кому всё? Вы такой умный, а мысль свою внятно объяснить не можете.

Видимо, DaylightIsBurning имел в виду, что под следующее описание из статьи


Но простой умный указатель — это не есть хорошо, т.к. агент B не будет удален (а значит и не будут освобождены ресурсы, которыми он владеет) пока у агента A есть умный указатель на агента B. Следовательно, нам в C++ пришлось бы использовать не просто умные указатели, а некие специальные умные прокси-ссылки. Агент А может иметь прокси-ссылку на B, но при этом B может быть безопасно удален не смотря на то, что прокси-ссылка у A продолжает оставаться.

хорошо подходит std::weak_ptr.


Причем A может попытаться отослать сообщение уже несуществующему агенту B и эта попытка не должна приводить к катастрофическим последствиям

Если коректно проверять weak_ptr перед использованием, то не приведёт.

Повторюсь: и?

Это что, была главная и единственная проблема? Или где-то утверждалось, что weak_ptr не может быть такой прокси-ссылкой?
Повторюсь: и?

И ничего.


Или где-то утверждалось, что weak_ptr не может быть такой прокси-ссылкой?

Или где-то утверждалось, что может?

И ничего.
Ну вот в том-то и дело, что ничего.
Или где-то утверждалось, что может?
Утверждалось, что есть две проблемы. И если для решения одной weak_ptr может применяться, то что со второй?

А если для решения второй проблемы weak_ptr не применим, то зачем заводить разговор о weak_ptr?
Но если проблема решается слабыми указателями, то почему она упоминается? Это не упрек, мне просто интересно, вероятно есть какие-то нюансы?
А вторую проблему, на первый взгляд, логичней решать создавая специальный актор-повторитель один ко многим и т.п.
Но если проблема решается слабыми указателями, то почему она упоминается?
Еще раз: какая проблема решается?

Вы видите часть проблемы, обнаруживаете какой-то знакомый вам паттерн и пишете в комментарии weak_ptr. Что я должен додумывать за вас дальше?

Вы считаете возможным в качестве условного agent_ref-а отдавать пользователям weak_ptr? Ну OK. Отдадите. Во-первых, тогда вы решите какую-то свою проблему, а не нашу. Во-вторых, вот возьмет пользователь и вызовет weak_ptr::lock и сохранит надолго возвращенный shared_ptr. Фактически это тоже самое, что вы просто будете обмениваться shared_ptr-ами напрямую. В-третьих, у вас реализация будет гвоздями прибита к shared_ptr/weak_ptr. И вы не сможете просто так поменять типы своих умных указателей (например, на указатели без атомарного счетчика ссылок для однопоточного режима работы). Получится, что вам все равно нужно отдать пользователю какой-то собственный agent_ref. Будет ли внутри него weak_ptr или что-то другое — это уже деталь реализации, от которой пользователь зависеть не должен.
А вторую проблему, на первый взгляд, логичней решать создавая специальный актор-повторитель один ко многим и т.п.
Ну решите ее с учетом того, что единственным механизмом взаимодействия акторов является асинхронный обмен сообщениями. Который, в принципе не надежен. Может вам понравится ваша реализация подписки/отписки для broadcasting actor-а исключительно на асинхронных сообщениях.
Почему этих рассуждений не было в посте?
Как минимум, две причины.

1. Пост и так получился довольно большим. Всегда приходится балансировать между тем, что можно впихнуть в текст и тем, что следует поместить в текст, чтобы текст оставался интересным и познавательным.

2. Когда ты погружен в тему, не всегда просто понять, какие очевидные для тебя вещи вовсе не являются таковыми для стороннего читателя.

Имхо, как раз комментарии нужны для того, чтобы люди могли задать вопросы к тексту. Например, вопрос «Почему weak_ptr не использовался в качестве прокси-ссылки на агента?» дает мне понять, что именно хочет узнать читатель. Тогда как реплика «weak_ptr же» оставляет меня в недоумении, я не понимаю, что хочет сказать человек, что он понимает, что принимает в расчет, что нет. Отсюда и попытка выяснить, для чего weak_ptr упомянут в комментарии.

Странно, лично мне очевидно, что реплика "weak_ptr же" сразу после цитаты "Следовательно, нам в C++ пришлось бы использовать не просто умные указатели, а некие специальные умные прокси-ссылки." как раз и означает вопрос "Почему weak_ptr не использовался в качестве прокси-ссылки на агента?"

А вот мне не очевидно и домысливать за собеседника я не берусь.
Исходя из текста, мне показалось, что Вы объясняете, почему ваш подход лучше, чем сырые указатели, фактически расписывая, как Вы реализовывали аналог weak_ptr. В то время как было бы интересно почитать, чем ваша реализация отличается weak_ptr и почему. Про отличия shared/weak_ptr от сырых указателей написано и в других местах, а про акторов — нет.
У меня возникло ощущение (м.б. ошибочное), что объяснение преимуществ [аналога]weak_ptr можно было вовсе опустить, тем самым сократив и упростив текст, не теряя в познавательности.
что Вы объясняете, почему ваш подход лучше, чем сырые указатели
Нет, такой цели не было. Была цель обрисовать условия, находясь в которых мы, в итоге, пришли к идее mbox-ов.
В то время как было бы интересно почитать, чем ваша реализация отличается weak_ptr и почему.
Так мы в конце-концов вообще ушли от того, чтобы акторы хранили ссылки друг на друга (тогда как другие фреймворки в этом плане следуют классической Модели Акторов). Вместо этого мы ввели дополнительный слой абстракции: почтовые ящики. У нас получается, что акторы для общения друг с другом должны использовать дополнительную сущность — mbox. Нет mbox-а — значит нет возможности общаться.

Это другой подход к организации взаимодействия между акторами. В чем-то он, наверное, хуже классической модели. В наших же сценариях он показался удобнее. Тем более, что со временем выяснилось, что под специфические задачи могут создаваться специфические mbox-ы со своей логикой.
Но акторы теперь хранят указатели на mbox (или наоборот).
Да, акторы хранят указатели на mbox-ы. А mbox-ы хранят указатели на акторов, которые на mbox подписаны. Но со списками указателей на акторов в mbox-ах все достаточно просто: когда актор уничтожается, он отменяет все свои подписки. Соответственно, указатель на этого актора удаляется из всех mbox-ах, в которых этот указатель присутствовал. Поэтому если актор A отсылал сообщения актору B через mbox X, то после исчезновения B, mbox Х продолжит существовать, но указателя на B в нем уже не будет.
Sign up to leave a comment.

Articles