Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Mon, 14 Aug 2006 22:15:02 +0100
From: Joe Orton <jorton@redhat.com>
To: APR Development List <dev@apr.apache.org>
Subject: Re: Problems with DSOs and Pools
Message-ID: <20060814211502.GA24628@redhat.com>
Mail-Followup-To: APR Development List <dev@apr.apache.org>
References: <7edfeeef0608110942h8caf669t96585359a5c61f17@mail.gmail.com>
 <20060814093826.GA11345@redhat.com>
 <7edfeeef0608141155q639c41detf46c8c653a47831f@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <7edfeeef0608141155q639c41detf46c8c653a47831f@mail.gmail.com>
User-Agent: Mutt/1.4.2.1i

On Mon, Aug 14, 2006 at 02:55:49PM -0400, Garrett Rooney wrote:
> I'm really just hoping for a way to make DSO loaded libraries just the
> same as any other library, if they require a whole lot of backflips to
> use reliably, that seems like a problem to me.

Of course, with DSOs there are some whole new lifetime issues to think 
about - it *is* difficult, no doubt about it.  Nesting pools properly 
and avoiding "global" pools helps with constraining the DSO to its own 
little short-lived world.

I'm not seeing anything at all here which needs changing in APR; just 
some application code which has not been designed in anticipation of 
being used from a DSO.  That is really not something which can or should 
be fixed in APR.  

Regards,

joe