apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Kenneth Casson Leighton <l...@samba-tng.org>
Subject Re: cvs commit: apr/locks/win32 locks.c
Date Wed, 06 Jun 2001 12:09:16 GMT
> 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.


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



View raw message