[asio-users] Socket/Acceptor cancelation on WinXP

[Norbert Wenzel]

I'm using a TCP server based on the Async HTTP Server example and Asio
from Boost 1.51. I had some problems where I thought some connections
did not close properly and caused the server to stay open. So I tried
out cancel() on the servers tcp::acceptor to stop all async_accept()
operations.

I did not encounter any problems (working on Win7) until on XP when the
call to cancel() failed with system error system:10045. I easily found
some old discussions about that topic that referred to the doc for
tcp::socket::cancel()[0]. There is a warning about the problems with
cancelation on XP.

When looking at the docs of tcp::acceptor::cancel()[1] there are no
warnings, but obviously the call to cancel() caused the exception on XP.
Replacing the simple call with cancel(error_code) (and later on ignoring
the error code) made the crash caused by the previously uncaught
exception go away.

So my question is if the warning should go be written on the
tcp::acceptor::cancel() doc page also, or if my error seems unrelated.

Norbert

[0]
http://www.boost.org/doc/libs/1_51_0/doc/html/boost_asio/reference/basic_stream_socket/cancel/overload1.html
[1]
http://www.boost.org/doc/libs/1_51_0/doc/html/boost_asio/reference/basic_socket_acceptor/cancel/overload1.html

[Igor R]

Post by Norbert Wenzel
When looking at the docs of tcp::acceptor::cancel()[1] there are no
warnings, but obviously the call to cancel() caused the exception on XP.
Replacing the simple call with cancel(error_code) (and later on ignoring
the error code) made the crash caused by the previously uncaught
exception go away.
So my question is if the warning should go be written on the
tcp::acceptor::cancel() doc page also, or if my error seems unrelated.

Well, "acceptor" is actually socket, so the above issue is applicable
to it as well.
Wouldn't you be better off calling close() instead?

[Norbert Wenzel]

Post by Igor R

Post by Norbert Wenzel
When looking at the docs of tcp::acceptor::cancel()[1] there are no
warnings, but obviously the call to cancel() caused the exception on XP.
Replacing the simple call with cancel(error_code) (and later on ignoring
the error code) made the crash caused by the previously uncaught
exception go away.
So my question is if the warning should go be written on the
tcp::acceptor::cancel() doc page also, or if my error seems unrelated.

Well, "acceptor" is actually socket, so the above issue is applicable
to it as well.

But still they have their own documentation differing from each other,
which I found was a bit confusing.

Post by Igor R
Wouldn't you be better off calling close() instead?

Yep, that's what I do now after reading that simply using close() is
recommended, but I found that only on the sockets documentation page.

I was just trying to close the socket as cleanly as possible in order to
prevent the server from staying opened, so I did shutdown the
connections and cancel all async tasks before closing the socket. And
that's where I encountered the surprising exception on XP.

Norbert

[Igor R]

Post by Norbert Wenzel

Post by Igor R

Post by Norbert Wenzel
So my question is if the warning should go be written on the
tcp::acceptor::cancel() doc page also, or if my error seems unrelated.

Well, "acceptor" is actually socket, so the above issue is applicable
to it as well.

But still they have their own documentation differing from each other,
which I found was a bit confusing.

Post by Igor R
Wouldn't you be better off calling close() instead?

Yep, that's what I do now after reading that simply using close() is
recommended, but I found that only on the sockets documentation page.

Yes, I believe this's a bug in the documentation.