id,summary,reporter,owner,description,type,status,milestone,component,version,severity,resolution,keywords,cc
9296,synchronous non-blocking support for boost::asio::ip::tcp::socket::connect(),Stephen C. Pope <stephen.pope@…>,chris_kohlhoff,"Currently the implementation of boost::asio::detail::socket_ops::sync_connect() makes connect operations on a TCP socket which is in non-blocking mode (i.e. via set_user_non_blocking()) behave like a blocking connect(), by calling poll_connect() to wait for the completion of a non-blocking connect.

I have scenarios where I need the connect operation to be non-blocking, but I do not want to use async_connect() because I need to be able to handle the completion of the connect operation synchronously but at a later time. A typical scenario is adapting code which already manages large numbers of non-blocking file descriptors/sockets via epoll(), whereby I want to initiate the connect operation on a boost::asio::ip::tcp:socket object but then pass its native_handle() to epoll to later reap the connect completion.

As for better or worse the current implementation of socket::connect() with a socket in non-blocking mode is expected to have completed the connect attempt upon return (i.e. boost::asio::errors::would_block or in_progress are not expected), a new basic_socket::non_blocking_connect() - or some such - with support down through the various layers would probably be called for.

At the moment, I am achieving what I need by side-stepping socket::connect like this:

{{{
   boost::asio::ip::tcp::socket socket(ios);
   boost::asio::ip::tcp::endpoint addr(...);
   boost::system::error_code ec;
   socket.open(addr.protocol, ec);
   // set various sockopts...
   socket.non_blocking(true, ec);

   // in lieu of a hypothetical socket.non_blocking_connect(addr, ec):
   ::connect(socket.native_handle(), addr.data(), socklen_t(addr.size()));
   ec = make_error_code(boost::asio::error::basic_errors(errno));
}}}
",Feature Requests,new,To Be Determined,asio,Boost 1.54.0,Problem,,,