Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 22
А почему использован std::map<>, а не unordered_map<>? Есть какие-то ограничения или просто «привычка»...?
> Следовательно, нам в C++ пришлось бы использовать не просто умные указатели, а некие специальные умные прокси-ссылки.
weak_ptr же
weak_ptr же
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?
Но если проблема решается слабыми указателями, то почему она упоминается? Это не упрек, мне просто интересно, вероятно есть какие-то нюансы?
А вторую проблему, на первый взгляд, логичней решать создавая специальный актор-повторитель один ко многим и т.п.
А вторую проблему, на первый взгляд, логичней решать создавая специальный актор-повторитель один ко многим и т.п.
Но если проблема решается слабыми указателями, то почему она упоминается?Еще раз: какая проблема решается?
Вы видите часть проблемы, обнаруживаете какой-то знакомый вам паттерн и пишете в комментарии 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 упомянут в комментарии.
1. Пост и так получился довольно большим. Всегда приходится балансировать между тем, что можно впихнуть в текст и тем, что следует поместить в текст, чтобы текст оставался интересным и познавательным.
2. Когда ты погружен в тему, не всегда просто понять, какие очевидные для тебя вещи вовсе не являются таковыми для стороннего читателя.
Имхо, как раз комментарии нужны для того, чтобы люди могли задать вопросы к тексту. Например, вопрос «Почему weak_ptr не использовался в качестве прокси-ссылки на агента?» дает мне понять, что именно хочет узнать читатель. Тогда как реплика «weak_ptr же» оставляет меня в недоумении, я не понимаю, что хочет сказать человек, что он понимает, что принимает в расчет, что нет. Отсюда и попытка выяснить, для чего weak_ptr упомянут в комментарии.
Странно, лично мне очевидно, что реплика "weak_ptr же" сразу после цитаты "Следовательно, нам в C++ пришлось бы использовать не просто умные указатели, а некие специальные умные прокси-ссылки." как раз и означает вопрос "Почему weak_ptr не использовался в качестве прокси-ссылки на агента?"
Исходя из текста, мне показалось, что Вы объясняете, почему ваш подход лучше, чем сырые указатели, фактически расписывая, как Вы реализовывали аналог weak_ptr. В то время как было бы интересно почитать, чем ваша реализация отличается weak_ptr и почему. Про отличия shared/weak_ptr от сырых указателей написано и в других местах, а про акторов — нет.
У меня возникло ощущение (м.б. ошибочное), что объяснение преимуществ [аналога]weak_ptr можно было вовсе опустить, тем самым сократив и упростив текст, не теряя в познавательности.
У меня возникло ощущение (м.б. ошибочное), что объяснение преимуществ [аналога]weak_ptr можно было вовсе опустить, тем самым сократив и упростив текст, не теряя в познавательности.
что Вы объясняете, почему ваш подход лучше, чем сырые указателиНет, такой цели не было. Была цель обрисовать условия, находясь в которых мы, в итоге, пришли к идее mbox-ов.
В то время как было бы интересно почитать, чем ваша реализация отличается weak_ptr и почему.Так мы в конце-концов вообще ушли от того, чтобы акторы хранили ссылки друг на друга (тогда как другие фреймворки в этом плане следуют классической Модели Акторов). Вместо этого мы ввели дополнительный слой абстракции: почтовые ящики. У нас получается, что акторы для общения друг с другом должны использовать дополнительную сущность — mbox. Нет mbox-а — значит нет возможности общаться.
Это другой подход к организации взаимодействия между акторами. В чем-то он, наверное, хуже классической модели. В наших же сценариях он показался удобнее. Тем более, что со временем выяснилось, что под специфические задачи могут создаваться специфические mbox-ы со своей логикой.
Но акторы теперь хранят указатели на mbox (или наоборот).
Да, акторы хранят указатели на mbox-ы. А mbox-ы хранят указатели на акторов, которые на mbox подписаны. Но со списками указателей на акторов в mbox-ах все достаточно просто: когда актор уничтожается, он отменяет все свои подписки. Соответственно, указатель на этого актора удаляется из всех mbox-ах, в которых этот указатель присутствовал. Поэтому если актор A отсылал сообщения актору B через mbox X, то после исчезновения B, mbox Х продолжит существовать, но указателя на B в нем уже не будет.
del
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почтовые ящики, которые и не ящики вовсе…