std::future::wait_for() not working in Boost UDP socket async receive operation
The good people over at stackoverflow were not able to help me with this issue that I expected to be trivial. I am writing a UDP server app with Boost that should listen on a socket for 5 seconds and if no datagram has been received within these 5 seconds, move on to do other things. After some research I decided to try the solution based on std::future. The problem is that the call to wait_for() always times out as if no data was received. But if I set a breakpoint on the line that executes after the timeout and that I inspect variables I see that the buffer contains the received datagram and the remote_endpoint object contains the address of the client. In other words the socket receive works as expected but the std::future::wait_for() does not react. why? Here is my test server code: { try { boost::asio::io_service io_service; boost::asio::io_service::work work(io_service); std::thread thread([&io_service]() { io_service.run(); }); udp::socket socket(io_service, udp::endpoint(udp::v4(), 10000)); char recv_buf[8]; for (;;) { ZeroMemory(recv_buf, 8); udp::endpoint remote_endpoint; std::futurestd::size_t recv_length; recv_length = socket.async_receive_from( boost::asio::buffer(recv_buf), remote_endpoint, 0, boost::asio::use_future); if (recv_length.wait_for( std::chrono::seconds(5)) == std::future_status::timeout) { printf("time out. Nothing received.\n"); } else { printf("received something: %s\n", recv_buf); } } io_service.stop(); thread.join(); } catch (std::exception& e) { printf("Error: %s\n", e.what()); } return 0; }
2016-11-29 5:55 GMT+08:00
The good people over at stackoverflow were not able to help me with this issue that I expected to be trivial.
I am writing a UDP server app with Boost that should listen on a socket for 5 seconds and if no datagram has been received within these 5 seconds, move on to do other things.
After some research I decided to try the solution based on std::future.
The problem is that the call to wait_for() always times out as if no data was received. But if I set a breakpoint on the line that executes after the timeout and that I inspect variables I see that the buffer contains the received datagram and the remote_endpoint object contains the address of the client. In other words the socket receive works as expected but the std::future::wait_for() does not react. why?
Here is my test server code:
{ try { boost::asio::io_service io_service; boost::asio::io_service::work work(io_service); std::thread thread([&io_service]() { io_service.run(); });
udp::socket socket(io_service, udp::endpoint(udp::v4(), 10000)); char recv_buf[8];
for (;;) { ZeroMemory(recv_buf, 8); udp::endpoint remote_endpoint; std::futurestd::size_t recv_length;
recv_length = socket.async_receive_from( boost::asio::buffer(recv_buf), remote_endpoint, 0, boost::asio::use_future);
if (recv_length.wait_for( std::chrono::seconds(5)) == std::future_status::timeout) { printf("time out. Nothing received.\n"); } else { printf("received something: %s\n", recv_buf); } } io_service.stop(); thread.join(); } catch (std::exception& e) { printf("Error: %s\n", e.what()); }
return 0; }
The problem only happens if you have previous timeout. You can call socket.cancel() in the timeout branch. I think the problem is that, if you don't call socket.cancel() on timeout, in the next round you're calling async_receive_from before the previous call completes, which is not allowed.
On 29/11/2016 16:26, TONGARI J wrote:
The problem only happens if you have previous timeout. You can call socket.cancel() in the timeout branch.
I think the problem is that, if you don't call socket.cancel() on timeout, in the next round you're calling async_receive_from before the previous call completes, which is not allowed.
Note that even if you call cancel(), you still aren't allowed to immediately call async_receive_from() again. You need to cancel *and then* wait without timeout for the future to be ready before you can make another request. This should be fast (since you're just waiting for the cancellation to complete) but may not be zero time. (If you were using completion handlers rather than futures, this is equivalent to waiting for the handler to be called with a cancellation error before making another request.)
2016-11-29 12:01 GMT+08:00 Gavin Lambert
On 29/11/2016 16:26, TONGARI J wrote:
The problem only happens if you have previous timeout. You can call socket.cancel() in the timeout branch.
I think the problem is that, if you don't call socket.cancel() on timeout, in the next round you're calling async_receive_from before the previous call completes, which is not allowed.
Note that even if you call cancel(), you still aren't allowed to immediately call async_receive_from() again.
You need to cancel *and then* wait without timeout for the future to be ready before you can make another request. This should be fast (since you're just waiting for the cancellation to complete) but may not be zero time.
(If you were using completion handlers rather than futures, this is equivalent to waiting for the handler to be called with a cancellation error before making another request.)
I think we're wrong about whether it's allowed to call async_receive_from() multiple times before it completes. It was from my impression that we can't do that, but skimming over the ASIO docs I found nothing says that. Experiments show that it works, so I think my argument in this regard was wrong, at least ASIO itself does not enforce the restriction. So calling socket.cancel() w/o waiting the cancellation to complete should be OK.
On 29/11/2016 11:09, TONGARI J wrote:
So calling socket.cancel() w/o waiting the cancellation to complete should be OK.
Yes indeed, this was the missing element. I added a call to socket.cancel() in response to the timeout condition and it worked. Thanks a lot! /~JC
On 29/11/2016 23:09, TONGARI J wrote:
I think we're wrong about whether it's allowed to call async_receive_from() multiple times before it completes. It was from my impression that we can't do that, but skimming over the ASIO docs I found nothing says that. Experiments show that it works, so I think my argument in this regard was wrong, at least ASIO itself does not enforce the restriction.
It's technically permitted but it's rarely a good idea to have multiple pending operations of the same type (eg. more than one read or more than one write) on the same socket/whatever, as it becomes undefined what order things end up at the other end, which is rarely acceptable. (You can sometimes get away with concurrent writes with UDP, if done carefully; you typically can't get away with it with TCP. It's almost never sensible to have concurrent reads with either.) And also because user code will tend to supply the same buffers for multiple such operations of the same type, and that's definitely not allowed to use the same buffer in multiple concurrent operations. It's ok to have a pending read and a pending write on the same socket/whatever (as long as they use separate buffers), but then you can't selectively cancel() one of them, which may not be what you want. (It is actually possible to cancel an individual operation in WinAPI, but I don't think ASIO exposes this; possibly this isn't supported on Linux or because ASIO's own API doesn't really provide operation handles to let you specify what you want to be cancelled.)
participants (4)
-
Gavin Lambert -
JC Francois -
jc.francois＠gmail.com -
TONGARI J