https://svn.boost.org/trac10/ticket/13496 <p> This is a restatement of the issue <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/2832" title="#2832: Bugs: Asio sync IO functions need timeout parameters (closed: wontfix)">#2832</a>, in a different form. </p> <p> It's clear there is an appetite to be able to perform a synchronous read with a timeout using asio. Issue <a class="closed ticket" href="https://svn.boost.org/trac10/ticket/2832" title="#2832: Bugs: Asio sync IO functions need timeout parameters (closed: wontfix)">#2832</a> raised this issue. The main objection there seemed to be the form in which the functionality was proposed. I don't think there was a fundamental objection to the requirement. </p> <p> Similar functionality DOES exist on the basic_socket_streambuf. You can set an "expiry". The read functionality in that class mirrors the code in the socket_opts::sync_recv, it just adds a timeout to the poll call (though it does also remove the initial blocking wait, but that would be easy to conditionalise). To me, this gives an obvious route for implementation within the socket class. </p> <p> Note that although I talk about sockets here, I suspect the same would/should apply to other forms. I have only been looking at this from a socket perspective as it's what I'm trying to do, and I have specifically been trying to solve the situation for sockets. I don't know whether this applies equally or not to other I/O types. </p> <p> Note that although the boost library is called "asio", the N4656 specification is more open, and is a more general networking library description, and doesn't use "asynchronous" in its name. </p> <p> Could consideration be given to this? At the moment for example, I don't believe that it's possible to use boost::asio to write something like a fully synchronous, thread-per-connection HTTP server that implemented a keepalive, since that would have to perform a blocking read for another request for the keepalive interval before terminating the connection. Now you may say, well you should be writing is asynchronously, but for some applications this much simpler model is more appropriate (low volumes of requests where each request is a POST that takes considerable time to process for example). And any general networking library ought to support being able to write such an application. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/13496 Trac 1.4.3