Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44E1244E.6030602@xbc.nu>
Date: Tue, 15 Aug 2006 03:33:02 +0200
From: =?UTF-8?B?QnJhbmtvIMSMaWJlag==?= <brane@xbc.nu>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: APR Development List <dev@apr.apache.org>
Subject: Re: Problems with DSOs and Pools
References: <7edfeeef0608110942h8caf669t96585359a5c61f17@mail.gmail.com>
 <20060814093826.GA11345@redhat.com>
 <7edfeeef0608141155q639c41detf46c8c653a47831f@mail.gmail.com>
 <20060814211502.GA24628@redhat.com>
In-Reply-To: <20060814211502.GA24628@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Joe Orton 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.
>   

This is all very well for applications, but for libraries this can be
really, really difficult. I wouldn't say there's a bug in APR, but IMHO
there's a huge usability problem. In the case of Subversion, we don't
have much control over all the uses of our libraries and bindings. Yes,
we control the command-line client, but that's really just a small part
of the picture.

Note that loading DSOs is not the only problem here; we have a similar
issue in a case where we need a global cache, but have no control over
when its created and -- most important -- when it's destroyed. We've
managed to work around this particular case with horrible, hard to
maintain tricks; but it would make our lives a lot easier if we could do
away with them.

It may not actually be necessary to add new functions to APR or
anything. An acceptable solution might be to serialize allocations from
the global pool, the way pool creation is serialized (IIRC). Allocating
from the global pool doesn't happen very often, and if we could safely
pass a NULL pool to apr_dso_load (or apr_hash_create, etc.), it think we
could live with the potential performance penalty.

-- Brane