Здравствуйте, paxerus, Вы писали:

P>я так понял пофлудить все горазды, а как что дельное сказать так....

Судя по иcпользованию метода shared_from_this, тип вашего объекта наследует от enable_shared_from_this. Такое наследование как правило нужно в случаях, когда из instance-метода необходимо передать shared_ptr, указывающий на текущий объект, во внешний метод\функцию.
Необходимым условием для этого (получение shared_ptr вызовом shared_from_this()) является наличие внешнего shared_ptr на ваш объект, т.е. "где-то" уже должен существовать shared_ptr, "владеющий" вашим объектом.

Касаемо кода

shared_from_this().reset();

вызов shared_from_this создает новый shared_ptr (внутренний, разделяемый между всеми экземплярами shared_ptr владеющими вашим объектом, счетчик которого >= 2, т.к. по крайней мере один shared_ptr уже ссылается на объект), у которого затем сбрасывается указатель на объект (и соотв. значение счетчика уменьшается на 1), т.е. полезный выхлоп от этого кода нулевой

Т.о., если вам нужно, чтобы объект жил пока идут асинхронные операции чтения\записи, и не держать при этом ссылку на объект где-нибудь еще, достаточно создать экземпляр объекта, инициализировать им shared_ptr и передать управлению вашему объекту, который будет "протаскивать" shared_ptr объекта (с пом. shared_from_this) через вызовы async_read\write методов asio, после вызова последнего read\write обработчика объект будет удален (конечно если нет других shared_ptr, кроме тех, которые переданы в методы async_read\write)
напр:

shared_ptr<connection> conn(new connection(...));
conn->run(); //асинхронный метод, connection сам отвечает за свое время жизни, передавая shared_ptr на себя в методы asio

ps: имхо, описанный выше подход ("самоуправление" жизнью соединения) хоть и имеет право на жизнь, но не очень юзабелен, т.к. может потребоваться вести учет соединений, управлять их количеством, убивать "зависшие соединения" и тд, т.е. осуществлять управление соединениями.