apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garrett Rooney <roo...@electricjellyfish.net>
Subject Re: apr_dbd: a generic SQL wrapper
Date Thu, 09 Dec 2004 15:06:49 GMT
Nick Kew wrote:
> On Thu, 9 Dec 2004, Garrett Rooney wrote:
> 
> 
>>Why does apr_dbd_open take a temp pool?  Can't it just create a scratch
>>subpool and destroy it at the end of the function?  I can't recall any
>>other public APIs that take multiple pools.
> 
> 
> I'm thinking in terms of the httpd struct and my previous architecture,
> where connections are allocated on the server pool, but we don't want
> to use that for transient things so I pass it the request pool for that.
> The prototypes there are
>   foo* open(apr_pool_t* ptmp, server_rec* s)
>   foo* acquire(request_rec*)
> either of which *may* cause a new connection to be opened if one
> isn't available.
> Secondly, registering the cleanup is optional: the first pool can be NULL.

This really seems kind of odd, and I'm wondering if it's just because of 
my Subversion background.  So the cleanup that closes the connection is 
registered with the first pool, but the dbd is actually allocated out of 
the second?  Why would you want to do that?  If you allocate from the 
second pool won't the memory be gone far before the cleanup runs?  I 
must be missing something here.

If the first pool is only used to set up a cleanup (maybe, if it's not 
NULL) then perhaps it shouldn't be part of this interface at all.  If 
the caller wants a cleanup run when a specific pool is destroyed the 
caller can set it up themselves.  Special casing the API for it just 
seems wrong.

-garrett

Mime
View raw message