Opened 9 years ago
#9296 new Feature Requests
synchronous non-blocking support for boost::asio::ip::tcp::socket::connect()
Reported by: | Owned by: | chris_kohlhoff | |
---|---|---|---|
Milestone: | To Be Determined | Component: | asio |
Version: | Boost 1.54.0 | Severity: | Problem |
Keywords: | Cc: |
Description
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));