apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: Patches for bug found in APR sockets (another attempt at explaining the issue)
Date Tue, 09 Dec 2003 11:02:45 GMT
Norman Tuttle wrote:

>  Jeff:
> I think you misunderstood my point here. The preallocation is actually 
> desirable as it gives the sockets closure relative to pool dynamics. In 
> simplified English, that means that we can allocate a socket structure 
> (apr_socket_create), and when we deallocate it,

i.e., when we clear the pool that the socket lives in

> all that we need goes 
> away. The problem with the code I modified is that it causes a 
> dependence to occur on a structure which may not be in the same 
> pool-space. If the pointer is instead copied to the preallocated 
> structure, I can get rid of the original value in a more local pool, and 
> let the socket take care of the data it needs when it is finished with 
> it. This enables us to have cleaner interface to the sockets. Otherwise 
> (if you take out the preallocation of the needed elements), you would 
> really have to specify somewhere in the docs that the structure being 
> pointed to would require persistence for the life of the socket. This is 
> really easier to manage through the socket itself.

besides copying the structure into the socket, you need to worry about updating

     apr_pool_t *pool;       (update with the socket's pool)
     char *hostname;         (apr_pstrdup() into the socket's pool)
     char *servname;         (apr_pstrdup() into the socket's pool)
     void *ipaddr_ptr;       (update with new address within socket's sockaddr)
     apr_sockaddr_t *next;   (just clear this one)

But this is so that the apr_socket_t and apr_sockaddr_t can be allocated from 
pools with different lifetimes?  I agree it is conceptually cleaner if the 
implied pool relationship is lifted.  In practice I can see how having the 
sockaddr live longer than the socket is reasonable, and current code supports 
that (right?).  But what is the use of having a socket that lives longer than a 

View raw message