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
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
--On Wednesday, April 16, 2003 8:14 AM -0400 Jeff Trawick
[EMAIL PROTECTED] 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
Justin Erenkrantz wrote:
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
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
