Felipe,
I guess it is MUST be mode/state in the socket when all pending recv operations are canceled and new recv calls are rejected BUT socket handle is still alive. Using this mode user can safely shutdown incoming data processing. Otherwise user should lock socket before call async_read/close/async_write.
On Mon, Jun 7, 2010 at 7:17 AM, Igor R <boost.lists@gmail.com> wrote:I see. You would call cancel first. Unfortunately cancelling is not
>> You would destroy the socket. Delete'ing it,
>
> So it would be always necessary to store a ptr to a socket? Then
> delete the socket, which was passed by reference to async_read()?
> Doesn't sound good, does it?
very reliable. But cancelling is what is conceptually right here IMHO.
It seems to me. If you call close you want the socket released. That a
>> or using a boost::optional.
>
> But it's not optional, according to its semantics...
zombie socket remains is a design problem. Zombie objects should be
avoided.
I don't think it can be implementable without unnecessary overhead though.
Regards,
--
Felipe Magno de Almeida
_______________________________________________
Boost-users mailing list
Boost-users@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users