Jibbity jobby
Jibbity jobby

Reputation: 1325

What error_code should the ReadHandler for boost::asio::async_read return when the stream is closed?

I'm trying to implement the following for arbitrary streams (with both read and write interfaces).

http://www.boost.org/doc/libs/1_39_0/doc/html/boost_asio/reference/AsyncReadStream.html

What I plan to do is to pass the stream to some client. The client async_writes to the stream and when there is no more data it then closes the stream.

The calling code async_reads from the stream until I assume that it gets some indication of the stream close state via the ReadHandler error_code. My questions are:

  1. What will this error_code be?

  2. Can I guarantee to transmit all the data using this mechanism?

  3. Is there a better way to do this?

Upvotes: 1

Views: 852

Answers (1)

sehe
sehe

Reputation: 392979

The bottom line is: it depends on the implementation. If you want to abstract that interface away, I'd suggest abstracting the implementation details behind your own interface.

If you /want/ to expose the Asio interface (why?) then you could create a composed IO operation that translates all expectable errors to a common contract.


For specific implementations, a simple test would suffice of course.

For sockets, the usual error code is eof (boost::asio::error::misc_errors::eof). Depending on the circumstances boost::asio::error::basic_errors::connection_reset or boost::asio::error::basic_errors::network_reset could occur.

If the io_service is halted, the service object is destructed or the socket is closed, boost::asio::error::basic_errors::operation_aborted or boost::asio::error::basic_errors::bad_descriptor could be expected.

All these are implementation dependent, of course. Different platforms may have different codes, different streams may have different codes.

Error Conditions

Instead of error codes you could try to make sure the error condition maps onto the same "thing" so clients will have a consistent interface.

Upvotes: 3

Related Questions