CODEWITHSUNDEEP
boostboost-asio
updogliu
updogliu

Reputation: 6255

What are possible errors of ip::tcp::socket.close()?

Per the documentation:

Note that, even if the function indicates an error, the underlying descriptor is closed.

What are the possible errors?

Besides, if an error occurs in socket.close(), will the result of socket.is_open() always be false in spite of any error in socket.close()?

Upvotes: 1

Views: 90

Answers (2)

Tanner Sansbury
Tanner Sansbury

Reputation: 51881

In general, when Boost.Asio depends on the OS implementation, then it will neither specify the conditions under which errors may occur nor the error codes that may be returned.

If error handling depends on the exact error code, then one can use the BSD API mapping documentation or consult the implementation to determine which OS calls are being made. In the case of basic_socket::close(), the implementation will use either close() or closesocket(). One can use the appropriate OS documentation to determine the error cases, as well as the error return values that are associated with Boost.Asio error codes located in asio/error.hpp.

As noted in basic_socket::close() documentation, the underlying descriptor will be closed regardless of an error. Furthermore, the SocketService Type Requirements mandates that a post-condition of close() is that is_open() returns false.

service.close(impl, ec); → !service.is_open(impl)

Also, while the Boost.Asio documentation is the most appropriate place to look for the specified behavior, the dated (2007-03-11) Networking Library Proposal for TR2 (Revision 1) based on Asio occasionally contains some helpful wording to understanding details:

error_code close(implementation_type& impl, error_code& ec);

... establishes the postcondition as if by POSIX close()

Upvotes: 1

sehe
sehe

Reputation: 392979

I haven't checked the documentation, but it makes sense if the socket has a protocol to explicitly shut down communication (think SSL).

If the shutdown sequence cannot be completed (because the endpoint is down/unreachable?) then that's an error, but the socket is still closed (so this side doesn't suffer a resource leak because of uncontrollable external factors)

Note

Remarks

For portable behaviour with respect to graceful closure of a connected socket, call shutdown() before closing the socket.

from the docs

Upvotes: 0

Related Questions