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 sockaddr?
