Hi Christopher, --- christopher baus <christopher@baus.net> wrote:
On Thu, 12 Jan 2006, christopher baus wrote:
Also when a connection is closed by a peer during a read operation what error should be expected?
eof, not_connected, fault, operation_aborted all seem reasonable.
For a TCP socket, I would expect it to return eof, since that is how TCP sockets work.
I tested it on Windows and it does indeed return eof. It might be worth while to document this with the read functions.
Yep, eof is the error for when the connection is cleanly closed by the peer. It is currently documented for the corresponding sync functions. I'm also planning to document all of the errors that can be returned by various operations.
Here's the class I'm using to track the socket state in my application code. I am setting the state in my event handlers (which is rather error prone), but asio could manage it internally.
Actually no, I don't think it's appropriate for asio to manage this state internally. Completion notification is decoupled from the originating object, which means that: - The completion handlers can execute in a different thread to that which is initiating operations, so some form of synchronisation would be required to update the state. - The socket object may not even still exist at the point when the completion notification is received. The knowledge of object lifetime and synchronisation is held in the application's design, so I think that the application is the only safe place to update this sort of information. However, in the programs that I have seen asio used in, there has been no need to maintain this sort of state. The state of the socket is instead reflected by the part of the program you're in (e.g. which event handler you're in). If the socket changes state you start using a different event handler. And it's not just socket state changes that can use this approach, but application protocol state changes as well. Cheers, Chris