Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 23307 invoked by uid 6000); 7 May 1999 20:16:07 -0000 Received: (qmail 23257 invoked from network); 7 May 1999 20:16:02 -0000 Received: from zap.ne.mediaone.net (24.128.120.74) by taz.hyperreal.org with SMTP; 7 May 1999 20:16:02 -0000 Received: (qmail 28046 invoked by uid 1000); 7 May 1999 20:15:40 -0000 To: new-httpd@apache.org Subject: Re: Context types in APR. References: <87emkshks6.fsf@zap.ne.mediaone.net> <37334117.D3B9BFB3@Golux.Com> From: Ben Hyde Date: 07 May 1999 16:15:39 -0400 In-Reply-To: Rodent of Unusual Size's message of "Fri, 07 May 1999 15:37:59 -0400" Message-ID: <87aevghc0k.fsf@zap.ne.mediaone.net> Lines: 26 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org Rodent of Unusual Size writes: > Ben Hyde wrote: > > > > No? It would seem to me that you only need to pass a pool > > to those functions that create objects for the API. > : > > The case, I assume, your concerned with is when the operation > > needs scratch space to work in, but that is not returned to > > the caller. Apache's standard solution to that has been to > > store a pool in the object, when it's created, for such things. > > What about the case of apr_os_f(x) that works on strings, not > APR objects? Or something that calls apr_os_f(x) under the covers, > but still appears to only need a string as input? WHat if there > *is* no APR object clearly associated with the topmost operation? I've no problem with passing a pool directly or indirectly to most functions when there is the slightest chance that over time they might need our tools. Since I think the pool has a thread pointer in it for blocking I don't see what the remaining problem contexts is solving is. - ben