Re: [boost] [asio] Tutorial 7 using strdup, new

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