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 <li51ckf02@sneakemail.com> wrote:

"Soren Dreijer" <dreijer@echobit.net> 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