httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Thorpe <>
Subject Re: mod_ssl to-do items
Date Fri, 07 Mar 2003 21:39:18 GMT
Hi (again :-),

* Justin Erenkrantz ( wrote:
> --On Thursday, March 6, 2003 12:42 PM -0500 Geoff Thorpe 
> <> wrote:


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


Geoff Thorpe

View raw message