Hi (again :-), * Justin Erenkrantz ([EMAIL PROTECTED]) wrote: > --On Thursday, March 6, 2003 12:42 PM -0500 Geoff Thorpe > <[EMAIL PROTECTED]> wrote:
[snip] > >> * session cache store should be pluggable > > > >I'd like to speak with the person who's behind this, as I'm waiting for > > (Pardon me while I go off on a tangent...) > > Note that there really isn't a single person who is responsible for > mod_ssl. The only person who may claim that is Ralf and he hasn't been > involved for years. All of us on this list are implicitly responsible. > Some people are more involved than others though - Madhu and DougM have > been beneficial to keeping it running though (among others that I have > forgotten right now - sorry!) - but the point of adding mod_ssl to our tree > was so that it could be group-maintained rather than a specific individual. > So, I wouldn't go look for a specific person to talk to. Whomever that > person would be should be reading this list. Just start having a > conversation about what you'd like to see happen on this list and people > will magically start to chime in. And, keep submitting patches about what > you'd like to see fixed - it's the surefire way of getting our attention. > (And, simply repost if you don't hear anything in a week...) Thanks for the tangent, it's good to know what the conventional wisdom is w.r.t. code management (it seems contributing to apache2's mod_ssl might be less troubled by long periods of silence than has been the case with apache1.3 mod_ssl sometimes :-). Nonetheless, I'd like to know who the person(s) are that are behind the statement in the STATUS file so that I can find out what it is (exactly) that they mean and what (if any) history there is to the idea. "session cache store should be pluggable" has an encouraging sound to it, but is somewhat unburdened by any concrete meaning that I can see. :-) > >> * the shmcb code should just align its memory segment rather than > >> jumping through all the "safe" memcpy and memset hoops > > > >I wrote shmcb and I don't think the person who wrote this quite > >understands why this "jumping through hoops" is done. Trying to align > >all the relevant data will cost more than just a few wasted bytes of > >storage, and I respectfully suggest that the "safe" accessors (which > >aren't speed-critical) would be easier to maintain. Again, I'm available > >to bash these ideas out if anyone's interested. > > It's probably under the idea that we'd save a few cycles and make the code > more understandable if we relied upon alignment. In fact, I believe the > second argument is the more compelling one. I find the safe calls a > tremendous difficulty in understanding the shmcb code (which, AIUI, is > broken right now). -- justin Broken? How so? As for the safe calls - if they're a difficulty then they should be clarified because the principle is very simple. However to be more constructive than that; they can probably be done away with completely without losing the design if I get approval to restructure ssl_scache_shmcb.c a bit. Namely, the various structures used in the layout/geometry could just be memcpy()d to/from the relevant locations rather than having references to them in which individual data elements are "safe"ly accessed one-by-one. The geometry/layout shmcb places on the shared-memory segment was reasonably-well thought out, but the code that implements it is more "organic" - it grew into its current shape as I attempted to prototype the storage model. A little bit of rewriting and rewiring would (I suspect) greatly simplify things and I'm reasonably confident they would obviate the need for the "safe" functions - the alignment correction would be implicit by memcpy()ing the larger non-primitive structures between non-aligned shared memory and aligned local variables. This would slightly increase the amount of memcpy() activity (which was the naive reason that the "safe" approach was used to begin with) but it may just as likely be an improvement if a couple of bigger memcpy()s turn out faster than lots of little ones. Certainly this wouldn't affect the handling of the raw session data itself, and so I doubt any amount of profiling would show the slightest difference one way or the other. Anyway, I can put that on my TODO list if there are people who'd accommodate it by reviewing and helping me test. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
