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

From: Giovanni P. Deretta (gpderetta_at_[hidden])
Date: 2006-02-08 12:24:18

Christopher Kohlhoff wrote:
> Hi Giovanni,
> 
> --- "Giovanni P. Deretta" <gpderetta_at_[hidden]> wrote:
> <snip>
> 
>>In the end asio::socket_ptr<Stream> would look at its pointed
>>object and decide if it needs dynamic allocation or not.
> 
> 
> I'm happy with such a solution provided that no requirement is
> made that any asio class (stream_socket, etc) must support
> copying.
> 

Yes, it would be in *addition* to a non copyable (but hopefully movable 
:) ) socket.

> But let me ask: why would this need to be part of asio at all?
> 
> Consider a hypothetical smart pointer copyable_ptr<T> that works
> as follows:
> 
> - checks if a type trait is_intrusively_refcounted<T>::value is
>   true, and if so is implemented in terms of intrusive_ptr<T>.
> 
> - checks if a type trait is_refcounted_value_type<T>::value is
>   true, and if so is simply implemented in terms of T.
> 
> - otherwise is implemented in terms of shared_ptr<T>.
> 
> Then all asio would need to do is implement the type traits
> for its own classes as appropriate.
> 

Would work but not as you think: the pointed object is not an asio 
asio::*_socket, but a set of object pointed to from the private members 
of asio::*_socket: a pointer to the demuxer, a "pointer" to the device 
(the file descriptor), a pointer to an SSL_CTX, a pointer to the buffer 
etc.  If you look at most asio sockets, they are nothing more than that 
(that or I'm really wrong here!! :) ). Some of this pointers are owned 
by the socket (and have all the same lifetime), other pointers (the 
demuxer for example) are not owned.

Your copyable_ptr would hold internally the full set of these pointers 
plus a (stateless) interface to use them (the asio::*_socket set of 
member functions). The whole set of pointers is reference counted (by a 
single counter as they all share the same lifetime). When the counter 
drop to zero, a deleters is called for each pointer that does the clean 
up (if the pointer is not owned by the copyable_ptr is not deleted).

It may be the case that some types of asio::*_socket have actual 
internal state (instead of a pointer to state). In this case the 
copyable_ptr would resort to dynamically allocate the socket and refcout 
it.

So to make copyable_ptr a separate lib, it would need formidable 
introspection powers to 'see' inside a asio::*_socket or each 
asio::*_socket should in some way (via trait classes) 'explain' its 
state. Because of this tight coupling i think that *if* such a class is 
really needed it should be part of asio.

BTW, when do you plan to release next version of asio?

-- 
Giovanni P. Deretta,