From: Giovanni P. Deretta (gpderetta_at_[hidden])
Date: 2006-02-07 10:11:36
Christopher Kohlhoff wrote:
> --- "Giovanni P. Deretta" <gpderetta_at_[hidden]> wrote:
>>Well, it behaves like a (smart) pointer (the last to exit
>>closes the door) so it should look like a (smart) pointer. Why
>>do you think it should have the same interface of a
>>stream_socket? What advantages would give you?
>>
>>(Btw, technically it would have the same interface, but you
>>would call members functions using -> instead of . )
>
>
> This idea has a couple of issues that I can see:
>
> - It does not allow an implementation to store additional state
> inside the socket object directly, so forcing a dynamic
> allocation on the implementation.
>
Looking at the current asio implementation looks like all state are
pointers (even the ssl streams) or container of pointers. This means
that as long as the pointed object is always the same (but its state
might change) they can freely be copyied. The last reference cleans
things up as usual. If you really really need non-pointer state for a
particulare socket type, well, you need dynamic allocation, but only in
that case. Btw, only asio::socket_ptr<> would pay for the eventual
dynamic allocation, asio::*_socket would not.
> - It does not address stream layering, as in:
>
> asio::ssl::stream<asio::stream_socket> s;
>
> or
>
> asio::buffered_read_stream<
> asio::ssl::stream<asio::stream_socket> > s;
>
> Each layer adds its own state, and the whole lot would need to
> be reference counted.
>
No, you make an asio::socket_ptr<asio::buffered_read_stream<
> asio::ssl::stream<asio::stream_socket> > >. Only the resulting
object need reference counting.
In the end asio::socket_ptr<Stream> would look at its pointed object and
decide if it needs dynamic allocation or not. If it does it dynamically
allocates it and it is *exactly like* a shared_ptr<Strem>, if it does
not (all state are pointers), it keep the object as internal state and
behaves as a collection of shared_ptrs to the pointed to objects. BTW,
in the end you always have dynamic allocation. There is no way around
it. But it usually it happens inside some C library (SSL_CTX for example
or win32 SOCKETS) or in the kernel. So the point is not preventing
dynamic allocation at all, but preventing unneeded extra allocation.
This complicates the desing a lot, so I'm not arguing that it should be
done (in fact i'm strongly in favour of the current interface, plus
movable sockets), but I think that *if*, after some experience with
asio, dynamic allocation of sockets is really needed *and* it is a real
bottleneck, it can be done as an optimization (with asio::stream_ptr).
-- Giovanni P. Deretta