Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of rooneg@gmail.com designates
 64.233.162.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=Zlq7NiZK98IkoT60HUvuGwA0e1Kk3hAN1MdtwJXrlyyLadhex3lADzAjq89UaVq5jbIFtISTgV+7yG7YP0rwjOVR5+T/BScC1G3VGKcQBcEKegsobfmTeksqwKPcDg8y1HQAhEar6Q95nbwfzg0o8N5I5sy5ZuSHS4jxc07+k7k=
Message-ID: <7edfeeef0608141442o1ed30e9ar7f576ea106788113@mail.gmail.com>
Date: Mon, 14 Aug 2006 17:42:28 -0400
From: "Garrett Rooney" <rooneg@electricjellyfish.net>
Sender: rooneg@gmail.com
To: "APR Development List" <dev@apr.apache.org>
Subject: Re: Problems with DSOs and Pools
In-Reply-To: <20060814211502.GA24628@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <7edfeeef0608110942h8caf669t96585359a5c61f17@mail.gmail.com>
	 <20060814093826.GA11345@redhat.com>
	 <7edfeeef0608141155q639c41detf46c8c653a47831f@mail.gmail.com>
	 <20060814211502.GA24628@redhat.com>

On 8/14/06, Joe Orton <jorton@redhat.com> wrote:
> 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.

But if it's not fixed in APR then we've basically determined that you
cannot write a library that uses APR and DSOs and exposes interfaces
to the outside world that involve pools, or apparently constant
strings, it seems, or if you do you have to impose all sorts of extra
requirements on the lifetimes of pools that calling code passes in.
That seems kind of unreasonable to me, especially since we have a
place (apr_initialize) that is in a perfect position to solve this
problem for us, why can't we use it?

-garrett