Hi there, * William A. Rowe, Jr. ([EMAIL PROTECTED]) wrote: > At 10:45 AM 3/20/2003, you wrote: > >Has anyone done any testing of shmht in 2.0? It quickly stops caching > >new sessions for me using Geoff Thorpe's swamp tool. If anyone does > >want to put effort into getting it working, I've attached a patch which > >contains some fixes: the conversion to the RMM code was not finished. > > +1, as long as this code remains in the tree, it's good for us to have > the very best code available.
Might I suggest that anyone interested in shmcb get in contact and we talk about cleaning that up first? As was discussed recently in another thread, there seems to be some concern about the use of the alignment-fudging accessor functions I put in there, and rather than trying to align shmcb's geometry (which is what is suggested in the STATUS file) I suggested that I rejig the code itself to blast the header structures on and off the shm segment directly - simplifying the code, removing alignment hassles, and (I believe) not affecting performance. For my part, I'm happy to do this and I would *certainly* feel better about doing it prior to shmht being unplugged from apache altogether. Call me paranoid if you like. Anyone following openssl lists will know why I've been a bit distracted of late. Apache's autoconf hooks for openssl was my first priority up until it was recently committed, and my second priority in turn is to submit distcache(.org) glue code for 2.1-dev too. In short, I'm ready to roll on shmcb work once the distcache hooks are sorted out - and this (BTW) may also be wise before culling shmht, because it provides another high-performance (if I might be so bold to say) cache alternative to shmcb. > I don't necessarily disagree for 2.1-dev, but we've sort of concurred that > users shouldn't have to switch modules or configuration significantly in > a given minor version (e.g. 2.0). Now I'm not arguing that's it's very > unlikely a user successfully used shmht.c, but as a matter of principle, > we shouldn't drop this away from 2.0. I agree, for the reasons you stated as well as the reason I mentioned above. There were lingering reports IIRC that shmcb was "broken", and in all my dealings with shmcb since writing it, this has generally meant "gcc has found another way on another platform to butcher the 'safe' accessor functions". All the more reason to think about getting the shmcb code more robust against such issues before pulling the plug on shmht. Cheers, Geoff -- Geoff Thorpe [EMAIL PROTECTED] http://www.geoffthorpe.net/
