Now that we're discussing about shmcb, I had another question - I see the following in shmcb.c
608 /* Work on the basis that you need 10 bytes index for each session 609 * (approx 150 bytes), which is to divide temp by 160 - and then 610 * make sure we err on having too index space to burn even when 611 * the cache is full, which is a lot less stupid than having 612 * having not enough index space to utilise the whole cache!. */ 613 temp /= 120; Is the comment on line 609 wrong OR is line 613 wrong ? -Madhu >-----Original Message----- >From: Geoff Thorpe [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 25, 2004 8:45 AM >To: [EMAIL PROTECTED] >Subject: Re: [STATUS] (httpd-2.0) Wed Mar 24 23:45:11 EST 2004 > > >On March 25, 2004 10:50 am, Joe Orton wrote: >> > I've asked on more than one occasion and had no response. >Why is this >> > comment here? From who and where does it come? Could it please be >> > either (a) discussed, or (b) removed? It happens to make >very little >> > sense, but I'd certainly be keen to hear if someone has >any rational >> > logic to the contrary. >> >> I'll try (a): why are the _safe_ memcpy wrappers needed if not simply >> to cope with the fact that the shmcb structures are not kept >> word-aligned within the shmem segment? > >Well that *is* exactly why the wrappers exist. :-) The >question is more >how to modify the design to obviate this issue without bloat >and waste, >because the segment is partitioned up into a geometry of "divisions", >each with meta-data and cache data compacted end to end. > >That said, a couple of 'char' primitives have already moved to larger >types, and another couple probably should too (I have a sneaking >suspicion this is part of the problem in that bug report from >HP). When >this is done, the space/geometry arguments may go out the >window (though >I'm still worried about what a 64-bit architecture and >tool-chain might >do if we rely on alignment). > >Hmm, perhaps after all I could remove the safe stuff by >removing the use >of the overlays. <ponders>. This is *not* just a question of aligning >structures though, it's a question of changing the way data is managed >and accessed, which is why the flippant STATUS note had been >bugging me. >However, that more fundamental change may be a worthwhile anyway ... ><sigh> OK, I will report back on this once I get down into the >bowels of >this code again chasing Ken's bug. Does this mean I've got some >volunteers to help test this if I do undertake to rewire the cache >internals? :-) > >Cheers, >Geoff > >-- >Geoff Thorpe >[EMAIL PROTECTED] >http://www.geoffthorpe.net/ > >
