On Thu, May 17, 2001 at 05:13:33PM -0700, Ian Holsman wrote: > so If I understand this thread correctly > > we could removing the locking code from the allocation routines > (for use in running apache2.0 ) without any penalty? > as we are using thread based pools ???? > > maybe this can be a config option on the apr configure script > (--disable-Memory-Pool-Locking ?) > > ..Ian > > (I know I could just wait for the SMS stuff to get fully implemented, but > Im thinking we could fix it now, and later on remove the config option when > SMS is fully integrated)
Well, it's a two-pronged problem: 1) httpd-2.0 has thread-local request pools, so locking in a pool that is by its very nature independent doesn't get you much and just serves to slow you down. How big of a slow down, I'm not sure. I seem to remember when I did my initial analysis it was quite noticable - but that doesn't mean too much. 2) However, APR is generic - removing the locks for threaded allocation could cause problems. If Subversion has threads, but has one global pool, race conditions will be now introduced (don't know if that is the case). That's much worse than the speed penalty introduced by doing too many locks. As Roy mentioned, there are some things that can be done with hierarchical allocators to fix this problem - ones that will specifically know whether a lock should be held or not. My guess is a new apr_sms_nolock_t would indicate that no locking should be done even if threads are present. However, this requires the pool stuff to be converted to apr_sms_t semantics first, and the request_rec (or connection's pool - not sure which one makes sense here) would be switched to apr_sms_nolock_t. (Just one suggestion - sure there are other ways to do this...) I'm muddling through the apr_uri stuff at the moment (moving it to apr-util), so I'm not sure if/when I can get to it. -- justin
