apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jus...@erenkrantz.com>
Subject Re: [PATCH] some progress with apr_socket_data_get()/apr_socket_data_set()
Date Wed, 16 Apr 2003 15:23:17 GMT
--On Wednesday, April 16, 2003 8:14 AM -0400 Jeff Trawick 
<trawick@attglobal.net> wrote:

> 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

Mime
View raw message