Re: [Boost-users] Why does async_connect() call listen()?

I don't see why it is necessary in this case, since the calling thread is not doing work that needs to be interrupted in case of calling io_service::stop. On Tue, May 20, 2014 at 9:49 PM, Soren Dreijer wrote:

Thanks for the clarification Niklas. I'll have to dig deeper and figure out what's blocking the listen() call on these machines.

On Tue, May 20, 2014 at 2:34 PM, Niklas Angare wrote:

...

"Soren Dreijer" wrote:

...

By coincidence, I ended up looking at a stack trace where my application calls async_connect() on a asio::ip::tcp::socket. Two things took me by surprise:

1. Asio calls listen() under the hood. Why does it do that when I'm just trying to make an outbound TCP connection?

The call is made by the class socket_select_interrupter. The socket it is calling listen() on is an internal one bound to 127.0.0.1. If a firewall interferes with that then the firewall is horribly bugged. I believe the socket is set up so that a thread that is blocking on a call to ::select() (for example in io_service::run()), can be interrupted from another thread. This interruption is probably used when io_service::stop() is called for example.

2. If the listen() call above is indeed required, why does it happen on

...

the same thread where I call async_connect()? I thought the point of the method was to defer the work to the reactor?

It only has to defer work that would block or that the documentation explicitly promises it will defer.

Regards

Niklas Angare

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users