[Asio]Question about error_code when socket::close
The documentation says, " Any asynchronous send, receive or connect operations will be cancelled immediately, and will complete with the boost::asio::error::operation_aborted error." Is this the only way that boost::asio::error::operation_aborted be passed to async handlers? I want to distinguish the error_code set by calling socket::close from any other ways (like system error, network error, etc), otherwise, I can't determine whether I should delete the object in async handlers, because some have already been deleted after I call socket::close. If boost::asio::error::operation_aborted definitely means "socket::close is called", I can distinguish this situation. I've tried using boost::weak_ptr with boost::bind,but the performance decrease dramatically. thx.
I want to distinguish the error_code set by calling socket::close from any other ways (like system error, network error, etc), otherwise, I can't determine whether I should delete the object in async handlers, because some have already been deleted after I call socket::close. If boost::asio::error::operation_aborted definitely means "socket::close is called", I can distinguish this situation.
It seems to be rather error-prone approach. One day, when your application will have grown a bit, you'll find yourself hunting weird segfaults / access-violations.
I've tried using boost::weak_ptr with boost::bind,but the performance decrease dramatically.
Did you run a performance profiler with fully-optimized application and really discovered that the bottle-neck is in shared_ptr's?! This would be really surprising...
participants (2)
-
Comet -
Igor R