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/
