On Tue, Jul 16, 2019, 23:54 Rainer Jung <rainer.j...@kippdata.de> wrote:
> Am 17.07.2019 um 01:30 schrieb Branko Čibej: > > On 16.07.2019 23:18, Rainer Jung wrote: > >> I had some need for using APR_POOL_DEBUG today and ran into a > >> situation where pool lifetimes needed a hint using apr_pool_join(). > >> That is all documented and fine, except that I was surprised to see, > >> that apr_pool_join() doesn't work unless the application itself is > >> also compiled with APR_POOL_DEBUG. I think that's not the intend, one > >> should be able to replace the apr library against a debug one during > >> lifetime. > >> > >> So IMHO apr_pool_join() in apr has to be a noop function when > >> APR_POOL_DEBUG is not defined, so that the function call is contained > >> in the application. > >> > >> Currently when the app is compiled without APR_POOL_DEBUG, then in > >> apr.h we only have > >> > >> #if APR_POOL_DEBUG || defined(DOXYGEN) > >> ... > >> #else /* APR_POOL_DEBUG or DOXYGEN */ > >> > >> #ifdef apr_pool_join > >> #undef apr_pool_join > >> #endif > >> #define apr_pool_join(a,b) > >> ... > >> #endif /* APR_POOL_DEBUG or DOXYGEN */ > >> > >> so apr_pool_join() would be an empty macro. > >> > >> Other pool debug functions seem to share the same fate: > >> > >> - apr_pool_owner_set() > >> - apr_pool_find() > >> - apr_pool_num_bytes() > >> - apr_pool_lock() > >> - and as mentioned apr_pool_join() > >> > >> Any opinion on whether we should introduce empty implementations > >> instead of empty macros for those all? > > > > What should apr_pool_join and the other pool debugging functions do if > > you're not debugging pools? They should be no-ops. So replacing them > > with empty macros makes sense. > > > > Or are you arguing that two libapr variants, one compiles with > > APR_POOL_DEBUG and one without, should be ABI- compatible? > > As far as I understand it, one should be able to replace the normal apr > library by a debug apr library at runtime and get pool debugging. There > should be no need to provide a apr debug compilation of the app itself. > > If an app needs calls to apr_pool_join() to guide the debugging, they > must be in the source code of the app and must not get compiled out. > > No-op would only be OK, if the app they are function calls to no-op > functions, but not if they get compiled out. > > So yes, I think it must be ABI compatible and except for the above 5 > functions it is. > > Regards, > > Rainer > But diagnostic macros are rarely ABI compliant. C++ code suffers the same pain. I don't believe we can or should support ABI between debug and release models with respect to these toggles, because we want deep introspection into the structures with no assurance of equivilance across opaque structures. What are implemented as functions must remain ABI compliant and we can implement no-ops for the non-debug runtime. Stefan Eising identified a number of headaches with pool debugging fairly recently, I'm all for fixing this, but I'm not altogether concerned that dropping in the debug binary of apr for code compiled against non-debug apr should have any effect whatsoever.
