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.)
Hmm. Do they really need multiple key/value pairs across libraries? Why can't the iol 'own' the socket data? It can then be a hash or something that the iol layer wants. Are we thinking of when there are multiple iol implementations competing? Bah.
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.
Store that key in the apr_socket_data? Another cheesy idea may be to use a linked list with the key in the structure. I'm just really thinking that for the general case, a key/value backing (like a hash) is overkill. I'm just not clear this is going to be more than 2 or 3 elements at most...
shrug
Perhaps it would be preferable to have no socket user data at all rather than a limit of exactly one item... unclear...
Yeah, unclear. -- justin
