apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@apache.org>
Subject Re: [PATCH] some progress with apr_socket_data_get()/apr_socket_data_set()
Date Wed, 16 Apr 2003 17:48:37 GMT
At 07:14 AM 4/16/2003, Jeff Trawick wrote:
>Justin Erenkrantz wrote:
>>--On Tuesday, April 15, 2003 7:39 PM -0400 Jeff Trawick <trawick@attglobal.net>
>>>You may have known that socket data is implemented as pool userdata in a
>>>manner that prevented multiple sockets from the same pool being able to use
>>>the same key for socket data.  Another problem is that any cleanup specified
>>>in the call to apr_socket_data_set() is run when the pool is cleaned up, not
>>>when the socket is destroyed (in contradiction to the doc).
>>Err, yeah, why is it pool_userdata at all?  I'm confused.  Isn't using pool's userdata
*way* overkill for this?  Can't it just store a void* or something in its internal structure?
 Why does it have to live longer than the socket structure itself?
>>Are we really wanting to support multiple socket_data instances per socket? If a program
wants that level, it seems it should just use the apr_pool_userdata directly rather than this
unnecessary abstraction.  KISS.
>The context where I see this as useful is with utility routines (e.g., support libraries)
that perform operations using the socket but don't have any leeway in how the app uses pools.
 (This is a natural for an iol implemented using a socket iol "enhancement" to APR, since
there is no leeway on interface in order to work with all unmodified APR apps.)
>The overhead of building a unique key for every get/set operation is a giant concern to
>Maybe there is a better idea for how to make the key unique without performing any expensive

Trivial, either create a text hash, or sprintf("%x") ... of the actual pointer to
the socket itself.  Some sort of base 64 or 96 coding would beat pure hex
in terms of lookups, etc.  Or can userdata use binary keys instead of text?
In that case the raw pointer would be good (namespace protected, of course.)

It might be good to document that pooldata prefixed with apr_xxxxxxxx will
generally refer to internal pool objects allocated and managed by apr, and
that users should choose another (similar) mechansim for naming their
own pooldata.


View raw message