> 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
