Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: domain of bojan@rexursive.com designates
 203.171.74.242 as permitted sender)
Message-ID: <20060818104223.xuh4s2yjkko4c8cg@www.rexursive.com>
Date: Fri, 18 Aug 2006 10:42:23 +1000
From: Bojan Smojver <bojan@rexursive.com>
To: dev@apr.apache.org
Subject: Re: Problems with DSOs and Pools
References: <7edfeeef0608110942h8caf669t96585359a5c61f17@mail.gmail.com>
	<7edfeeef0608141155q639c41detf46c8c653a47831f@mail.gmail.com>
	<20060814211502.GA24628@redhat.com> <44E1244E.6030602@xbc.nu>
	<20060815101922.GA24682@redhat.com> <44E1A999.2080808@xbc.nu>
	<44E1E724.6050602@rowe-clan.net>
	<7edfeeef0608161356m5083ce65x728060445378b554@mail.gmail.com>
	<7edfeeef0608161429p317668eaofedfd0ff9e89d1b@mail.gmail.com>
	<20060817111548.GA4393@redhat.com>
	<7edfeeef0608170827u96bebb6ga914f1b78798e496@mail.gmail.com>
In-Reply-To: <7edfeeef0608170827u96bebb6ga914f1b78798e496@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	DelSp="Yes";
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.2)

Quoting Garrett Rooney <rooneg@electricjellyfish.net>:

> So you're saying that it should be impossible to use pools within a
> DSO loaded module without either absolute control over when those
> pools were created relative to the one that loads the DSO or taking
> extreme measures within the DSO to work around the various problems
> that can occur when the DSO is unloaded?  I'm sorry, but that seems
> really really wrong to me.

This is probably a stupid suggestion, but here it goes nevertheless...

 From what I can tell from the manual page of dlopen() on Linux, every =20
time a new DSO is loaded, a reference count is increased, but the =20
shared object file is loaded only the first time. So, the OS actually =20
doesn't do the job multiple times, but only once. Meaning, loading the =20
same DSO multiple times isn't really going to load the new DSO, but =20
will give an already existing handle. So, to really unload the DSO, =20
the apr_dso_unload() must be called the same number of times as =20
apr_dso_load() (unless someone's been calling dlopen()/dlclose() =20
directly in the meantime - which is something we cannot deal with).

If we were to have the "magical" DSO pool (access to which would have =20
to be serialized via a mutex) and have a hash in there of which DSOs =20
have been loaded, we could simply ignore any subsequent requests to =20
apr_dso_load(), serve the pointer we have in the hash and increase our =20
own counter. The dso_cleanup() can then become a no-op in terms of =20
dlclose(). It would only decrease the reference count, kept in the =20
hash. Once the reference count comes to zero, we still don't do =20
dlclose() in dso_cleanup(), but rather leave to the next =20
apr_dso_load(). If user counts on things being the same after that =20
point, then this would still be a problem, but I'm hoping that's not a =20
requirement.

This way, there would be no need to have another API call and things =20
would work with no crashes. I'm just not sure if the dlopen() =20
semantics as explained for Linux apply to other OSes and their DSO =20
support...

--=20
Bojan