Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 41849 invoked from network); 4 May 2006 09:18:11 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 4 May 2006 09:18:11 -0000 Received: (qmail 31909 invoked by uid 500); 4 May 2006 09:17:37 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 31387 invoked by uid 500); 4 May 2006 09:17:30 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 31122 invoked by uid 99); 4 May 2006 09:17:28 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 May 2006 02:17:28 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [80.229.52.226] (HELO asgard.webthing.com) (80.229.52.226) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 May 2006 01:46:34 -0700 Received: from asgard (asgard [192.168.10.2]) by asgard.webthing.com (Postfix) with ESMTP id 472D66451C for ; Thu, 4 May 2006 09:46:12 +0100 (BST) From: Nick Kew Organization: WebThing Ltd To: dev@apr.apache.org Subject: Re: Thread pool prototype Date: Thu, 4 May 2006 09:46:08 +0100 User-Agent: KMail/1.8.3 References: <4455B86E.6000701@ztune.net> <20060504140404.6ee534x068g0wkww@www.rexursive.com> <20060504041021.GG774@yi.org> In-Reply-To: <20060504041021.GG774@yi.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605040946.10564.nick@webthing.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On Thursday 04 May 2006 05:10, Tyler MacDonald wrote: > Looking through the existing status codes, it looks like returning > "APR_ENOMEM" would be best. That doesn't really help unless we can sensibly map _all_ DBD driver error codes to APR error codes. Or perhaps just live with heavy overuse of APR_EGENERAL (as in other areas more recent than the APR statuses were originally defined). A possible wheeze (for 1.3?) would be to return APR codes for all errors (with lots of EGENERAL), and introduce a new int apr_dbd_errnum(driver); to get the driver-specific errnum. -- Nick Kew