Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Date: Wed, 6 Jun 2001 14:09:16 +0200
From: Luke Kenneth Casson Leighton <lkcl@samba-tng.org>
To: David Reid <dreid@jetnet.co.uk>
Cc: dev@apr.apache.org
Subject: Re: cvs commit: apr/locks/win32 locks.c
Message-ID: <20010606140916.L7921@angua.rince.de>
Mail-Followup-To: David Reid <dreid@jetnet.co.uk>, dev@apr.apache.org
References: <20010606000746.69393.qmail@apache.org>
 <009101c0ee7e$8c60ad90$7f00a8c0@VAIO>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <009101c0ee7e$8c60ad90$7f00a8c0@VAIO>;
 from dreid@jetnet.co.uk on Wed, Jun 06, 2001 at 12:47:56PM +0100

> The patch went in as we've been talking a lot about moving sms forward but
> we need stuff like locks and file access to start adding some of the things
> we'd like.  Now we have it we can start fleshing out our ideas and probably
> add more code and modules.

so, let me try to [mentally] get this straight.

apr_sms needs locking.  most of the locking code is pool-based.

therefore, there are three alternatives:

1) make the locking code depend directly on an apr_sms_t instance
not an apr_pool_t instance.

a study should be done to determine whether this is feasible:
it may well be, as long as you use, say.... an apr_sms_tracking_t
or any other apr_sms that does tracking/cleanup.

2) make the locking code independent of apr_pool_t _and_ apr_sms_t.

either:

- get the locking code to not allocate any of its own memory, but
to have all the memory it needs passed in to it.

- give the locking code a 'get_me_some_memory_of_size_x()' function,
where it doesn't _give_ a monkeys where the memory comes from.

i.e. the locking code becomes a truly portable library that could
easily be compiled into a separate .so or .a and used totally
independently of apr.

3) work out a series of dependencies such that the locking code
remains using apr_pool_t.

as [uh, help!  i deleted context] greg! [i think!  sorry!] mentions,
add a pool to apr_sms_t.  it works, but therein lies danger:
apr_sms_t is supposed to be totally independent of apr_pool_t,
possible to compile stand-alone etc.

forcing it to compile/link with apr_pool_t is a slippery slope:
trust me on this one :)


> It'd be possible to remove the stuff I committed and add a pool to each
> apr_sms_t structure.  This would be used for allocating locks and other
> things in APR.   

you then have circular dependencies, or at least, a very awkward
set of dependencies where you have to have at least one apr_sms
instance that _doesn't_ rely on a pool.

anyway, i suppose i'd better go and earn some $ now.

ttfn,

luke