Attempting to understand the implementation it feels like this could be made to work. Indeed on Windows, it DOES work. So on Windows, manually setting SO_RCVTIMEO causes the socket_ops::recv call in socket_opts::sync_recv to return a timeout error (boost::asio::error::timed_out I believe). This causes the sync_recv call to return that error, and all is well. On Linux, the error returned by the socket_ops::recv appears to be boost::asio::error::try_again, and this causes sync_recv to then call poll waiting for the socket to become ready. Since there are almost certainly other things going on in this loop, other situations and error codes to consider, I can't say for certain, but it feels like there would be some logic here that could make a receive timeout work.

On Mon, 2018-03-19 at 14:21 +0000, Thomas Quarendon via Boost-users wrote:

...

On 19 March 2018 at 10:33 tom@quarendon.net wrote:

Attempting to understand the implementation it feels like this could be made to work.

Interestingly I notice that the basic_socket_streambuf class (in 1.67 at least), in accordance with the N4656 draft specification, DOES have support for timeouts. It implements the overflow and underflow calls using lower level asio calls, somewhat shadowing the implementation of socket_ops::sync_recv, but, crucially, not attempting an initial blocking read, then passing a timeout to the "poll_read" call:

// Wait for socket to become ready. if (detail::socket_ops::poll_read( socket().native_handle(), 0, timeout(), ec_) < 0)

This would seem to suggest that fundamentally, reading with a timeout can be made to work, as it works fine here.

If this doesn't work out for you, here's another way - it relies on the fact that you can create an asio socket object from a socket handle, and that socket object can be owned by a different io_context. This allows us to reserve a thread for a separate utility context: std::string read_line_with_timeout(boost::asio::ip::tcp::socket &sock, boost::asio::streambuf &buf) { namespace asio = boost::asio; // these statics could of course be encapsulated into a service object static asio::io_context executor; static asio::io_context::work work(executor); static std::thread mythread{[&] { executor.run(); }}; auto temp_socket = asio::generic::stream_protocol::socket(executor, sock.loca l_endpoint().protocol(), dup(sock. native_handle())); auto timer = asio::deadline_timer(executor, boost::posix_time::milliseconds(3000)); std::condition_variable cv; std::mutex m; int done_count = 0; boost::system::error_code err; auto get_lock = [&] { return std::unique_lock<std::mutex>(m); }; auto aborted = [](boost::system::error_code const &ec) { return ec == boost::asio::error::operation_aborted; }; auto common_handler = [&](auto ec) { if (not aborted(ec)) { auto lock = get_lock(); if (done_count++ == 0) { err = ec; boost::system::error_code sink; temp_socket.cancel(sink); timer.cancel(sink); } lock.unlock(); cv.notify_one(); } }; async_read_until(temp_socket, buf, '\n', [&](auto ec, auto&&...) { common_handler(ec); }); timer.async_wait([&](auto ec) { common_handler(ec ? ec : asio::error::timed_out); }); auto lock = get_lock(); cv.wait(lock, [&] { return done_count == 2; }); if (err) throw boost::system::system_error(err); std::istream is(&buf); std::string result; std::getline(is, result); return result; }

So, for non SSL usage, replicating the same kind of logic that basic_socket_streambuf does would seem like it would work. However, that won't work for SSL. You'd basically have to create your own socket class that did this, and then wrap that in the ssl_stream.

IMHO at least, having an equivalent of the "expiry" functionality provided by basic_socket_streambuf but at the tcp::socket class level would seem desirable. It seems odd that this functionality is considered useful by the N4656 draft specification at the basic_socket_streambuf level, but not at the tcp::socket level. And looking at what basic_socket_streambuf does, it wouldn't seem like it would be that complex.

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

This ticket may explain why things are the way they are. Personally, we use deadline_timer and it works (I think) https://svn.boost.org/trac10/ticket/2832 On Tue, Mar 20, 2018 at 2:16 PM, Thomas Quarendon via Boost-users < boost-users@lists.boost.org> wrote:

...

This is probably going to seem like an overly flippant answer, but I do firmly believe that it is the *only* correct answer.

Not at all, you're quite right, and I'm aiming in that direction.

My investigations have bifurcated in a way. On the one hand, I'm interested from an academic point of view in why it is I can't do a sync read with timeout. So lets say I'm using asio to write a more traditionally structured synchronous blocking thread-per-connection model server. Sync all the way. I can't implement a read timeout, well, not in a way that's directly provided by the library. The only ways to do it require mixing in some async, and the only methods that exist are really workarounds from what I can see. Yet if I want to wrap an iostream around a socket using basic_socket_streambuf, and perhaps code it that way I *CAN* do a sync read with timeout, directly supported by the library. Given the intention of the draft standard that backs asio, this seems like an oversight to me.

On the other hand, how should I be implementing my server? As you say, a way of mixing sync and async is to have a fully async "front end" that would deal with bad clients and sanitise the input. This could run on only thread and handle many thousands of concurrent connections quite easily, as it would never block. What it would then want to do though is use an async write to put data onto an internal pipe. Then a dedicated worker thread can use a sychronous read to read off that queue. The front end can close it's end of the pipe if it has detected a bad/slow client and worker thread will see an EOF, there's no need for the worker thread to worry about read with timeout. The nice thing is that you get natural flow control, the front end won't read more off the input socket until the write to the internal pipe has completed, which it will only do if there's space, so you won't have to implement flow control manually.

On Linux you can do that, since you can create an anonymous pipe easily and wrap it with asio. You can't create anonymous pipes on Windows though, so you have to create named pipes in the operating system, which is going to add overhead. What you would *really* want is a fully user mode pipe implemented purely within asio and not going down to the kernel at all, apart from use of mutex and condition variable. But then I've just invented zeromq. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

Then a dedicated worker thread can use a sychronous read to read off that queue.

This argues for a separate io_context for use by that thread. On Tue, 2018-03-20 at 14:16 +0000, Thomas Quarendon via Boost-users wrote:

...

This is probably going to seem like an overly flippant answer, but I do firmly believe that it is the *only* correct answer.

Not at all, you're quite right, and I'm aiming in that direction.

My investigations have bifurcated in a way. On the one hand, I'm interested from an academic point of view in why it is I can't do a sync read with timeout. So lets say I'm using asio to write a more traditionally structured synchronous blocking thread-per-connection model server. Sync all the way. I can't implement a read timeout, well, not in a way that's directly provided by the library. The only ways to do it require mixing in some async, and the only methods that exist are really workarounds from what I can see. Yet if I want to wrap an iostream around a socket using basic_socket_streambuf, and perhaps code it that way I *CAN* do a sync read with timeout, directly supported by the library. Given the intention of the draft standard that backs asio, this seems like an oversight to me.

On the other hand, how should I be implementing my server? As you say, a way of mixing sync and async is to have a fully async "front end" that would deal with bad clients and sanitise the input. This could run on only thread and handle many thousands of concurrent connections quite easily, as it would never block. What it would then want to do though is use an async write to put data onto an internal pipe. Then a dedicated worker thread can use a sychronous read to read off that queue. The front end can close it's end of the pipe if it has detected a bad/slow client and worker thread will see an EOF, there's no need for the worker thread to worry about read with timeout. The nice thing is that you get natural flow control, the front end won't read more off the input socket until the write to the internal pipe has completed, which it will only do if there's space, so you won't have to implement flow control manually.

On Linux you can do that, since you can create an anonymous pipe easily and wrap it with asio. You can't create anonymous pipes on Windows though, so you have to create named pipes in the operating system, which is going to add overhead. What you would *really* want is a fully user mode pipe implemented purely within asio and not going down to the kernel at all, apart from use of mutex and condition variable. But then I've just invented zeromq. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

On 21/03/2018 03:16, Thomas Quarendon wrote:

On Linux you can do that, since you can create an anonymous pipe easily and wrap it with asio. You can't create anonymous pipes on Windows though, so you have to create named pipes in the operating system, which is going to add overhead. What you would *really* want is a fully user mode pipe implemented purely within asio and not going down to the kernel at all, apart from use of mutex and condition variable. But then I've just invented zeromq.

https://msdn.microsoft.com/en-us/library/windows/desktop/aa365152.aspx There are even ways to pass anonymous pipe handles explicitly to another already-running process (with cooperation on both sides), which I don't think is possible in Linux. Granted, this is still an OS pipe, but there isn't that much overhead, especially within a single process. Still, there's no reason to create pipes for inter-thread communication. You're in a shared memory space, and ASIO is itself a queued-task management system, and you can store arbitrary state for each task (including completely unique structures for each task, if you really want). Just store the data you want to process directly in the object that you're posting to the other io_service, then store the result in the object that you post back for completion. If you want to stick with a data-stream structure, you could use a Boost.LockFree queue, or a regular queue protected by mutex, or any other data structure that fits your purpose.

On 22/03/2018 22:56, Thomas Quarendon wrote:

Yes, sorry. Yes, you can create pipes in Windows, but asio doesn't support Windows anonymous pipes or concole handles, as they don't support completion ports. But yes, you can create a named port with a unique name (which is what CreatePipe does).

Anonymous pipes created with CreatePipe don't support overlapped I/O, true; but as you said yourself they're just named pipes with a unique name, and CreateNamedPipe *can* support overlapped I/O, so you can make up your own name and use them with a windows::stream_handle to do async reads and writes. It's a little more fiddly but you can also compose your own I/O objects and operations around other APIs, presumably such as TransactNamedPipe. I have some code that turns a shared memory block (with events) into a simple one-slot interprocess ASIO-compatible async mailbox, for example; the key trick was to use windows::object_handle::async_wait to "wait" for something to happen and then read the data synchronously in the wait completion handler (because at that point it is guaranteed to complete without blocking).

Using async initially, then sync to read the "message" works well, it's a nice design, if only I could put a timeout on the synchronous reads.

You can use a deadline_timer and cancel the synchronous read if it trips. It's a bit fugly though and is subject to races. It's much nicer to use async.

On Fri, 23 Mar 2018 at 09:07, Thomas Quarendon via Boost-users < boost-users@lists.boost.org> wrote:

...

You can use a deadline_timer and cancel the synchronous read if it trips. It's a bit fugly though and is subject to races. It's much nicer to use async.

The point is though that I don't think this works. This is what I started with. It works on Windows OK. But on Linux, calling "cancel" or "close" on a socket doesn't cancel a synchronous read call. This is what started me down this whole route.

This seems unlikely. I have been using asio in production code on Linux for 4 years. Can you post a mcve so I can test?

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

forgive me. I read "a synchronous call" as "asynchronous call". Of course the correct way to "cancel" a sync call in linux is to raise a signal, which should cause the socket's read to return with EINTR. But before I realised my mistake, I wrote this little test to prove that async calls are canclled :) Maybe someone will find it useful... #include <cstdlib> #include <sys/types.h> #include <sys/wait.h> #include <iostream> #include <string> #include <boost/asio.hpp> using namespace std::literals; namespace asio = boost::asio; using protocol = asio::ip::tcp; void server(protocol::acceptor& acceptor, int child_pid) { acceptor.listen(); auto& executor = acceptor.get_io_context(); auto sock = protocol::socket(executor); auto timer = asio::system_timer(executor); acceptor.accept(sock); auto read_handler = [](auto ec, auto...) { if (ec) std::cerr << "read handler error: " << ec.message(); else std::cerr << "strange - we expected an error"; }; auto timer_handler = [&](auto ec) { if (not ec) { sock.cancel(); } }; sock.async_read_some(asio::null_buffers(), read_handler); timer.expires_after(1s); timer.async_wait(timer_handler); executor.run(); auto data = "foo"s; sock.write_some(asio::buffer(data)); int status = 0; waitpid(child_pid, & status, 0); } void client(asio::io_context& executor, protocol::endpoint server_endpoint) { protocol::socket sock(executor); sock.connect(server_endpoint); auto on_read = [](auto, auto) {}; sock.async_read_some(asio::null_buffers(), on_read); executor.run(); } int main() { auto executor = asio::io_context(); auto acceptor = protocol::acceptor(executor); acceptor.open(protocol::v4()); acceptor.bind(protocol::endpoint(protocol::v4(), 0)); auto server_endpoint = acceptor.local_endpoint(); executor.notify_fork(asio::io_context::fork_prepare); int child_pid = fork(); if (child_pid < 0) { std::cerr << "fork failed" << std::endl; std::exit(100); } else if (child_pid > 0) { executor.notify_fork(asio::io_context::fork_parent); server(acceptor,child_pid); } else { executor.notify_fork(asio::io_context::fork_child); client(executor, server_endpoint); } return 0; } expected output:

*read handler error: Operation canceled*

On 23 March 2018 at 08:44, Thomas Quarendon via Boost-users < boost-users@lists.boost.org> wrote:

...

This seems unlikely. I have been using asio in production code on Linux for 4 years. Can you post a mcve so I can test? Yes, the code I started this thread with: https://gist.github.com/tomq42/331b8d48110c5025e0fce93e689bd5a3

I don't think this is a surprise. As far as I understand it, "cancel" isn't expected to cancel a *synchronous* read from the socket. It's more of a surprise to me that calling close on the socket doesn't have the effect of causing the read to return with an error. Both of these things work on Windows, and I started out on Windows, so the code was all fine there. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users

Of course the correct way to "cancel" a sync call in linux is to raise a signal, which should cause the socket's read to return with EINTR.

Hmm. Can't see any evidence of it working in my test. I've made my deadline callback do a raise(SIGALRM). If I don't have a handler for that signal, then my process terminates, which I guess is fair enough. If I have a (boost asio) handler and essentially ignore the signal (just print "signal handled" from my signal handler), the signal is handled, but my read doesn't return. My recollection of the boost asio code for socket recv is that it doesn't simply perform a raw socket recv call, but rather it loops in case of error, with a "poll" call in there too. So while that technique may work OK for a raw socket, it doesn't work with asio.

Yeah, it's a mess compared to Windows CancelSynchronousIO Quite. Yuck!

All I want is to be able to pass a timeout to the poll call that asio makes on my behalf! The operating system gives me what I want, I just can't get at it.