At 07:14 AM 4/16/2003, Jeff Trawick wrote:
>Justin Erenkrantz wrote:
>>--On Tuesday, April 15, 2003 7:39 PM -0400 Jeff Trawick <[EMAIL PROTECTED]>
>>wrote:
>>
>>>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 me.
>
>Maybe there is a better idea for how to make the key unique without performing
>any expensive operations.
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.
Bill
