On Oct 23, 2003, at 10:07 AM, Ronald Landheer-Cieslak wrote:
On Thu, Oct 23, 2003 at 06:24:34AM -0700, James Berry wrote:I don't particularly like the idea of overloading the alignment defineFWIW, I'm running tests with 16-byte alignments (delayed because of the birth
to serve a completely different purpose. Yes, 0 is an illegal value for
this define, (it would presumably result in a divide by zero as we take
ptrSize % alignment). But that doesn't mean it's a good idea to
overload the illegal value for this define in order to imply something
completely different about how XMemory should function.
So: if we need to alter the way XMemory works, we should come up with a
separate mechanism for doing that.
But: You haven't convinced me that any of this is necessary.
I was the person who initially brought up the issue of the pointer alignment, and I'm still somewhat bothered by the need to tack on the block header. But I'm not sure we should further complicate this code with yet another option...when it hasn't been shown that there is any reason to do so.
Do you have any compelling reason why we need this additional option?
An answer that "MSVC uses 16 byte alignment" is not sufficient for me:
my answer would simply be "then we've got a bug in the MSVC port, don't
we? (where we might presumably need to set
XML_PLATFORM_NEW_BLOCK_ALIGNMENT to 16)".
You brought up this issue because you'd seen some instability in your code. Have you shown that:
(a) This issue is due to the block header or pointer alignment? (b) This issue can't be fixed by setting XML_PLATFORM_NEW_BLOCK_ALIGNMENT?
of my daughter). I'll probably have results after the week-end. I have not
proven so far that the alignment is actually the problem, but it does bother
me (I have a gut feeling that it might be the problem, which is why I'm
running a 16-byte aligned test).
As for the 0-byte alignment: it bein illegal is documented in /dev/null and
pretty har to find. It being suggested to me as a solution kinda shows that.
The patch is intended to make it work properly, and is intended to provide
an easy "quick fix" for platforms for which the proper alignment is hard to
find for some reason (missing documentation, no time to experiment, etc.) If
you want a separate system, such a system can be devised w/o too much trouble.
As for convincing you that such a system is necessary: it will come in handy
w/o the shadow of a doubt, but it is not a requirement in the strict sense
of the term as that it will make any value < the pointer size legal - it just
gives some easily documentable and handy properties to not aligning, which
IMHO is the behaviour one would expect from setting
XML_PLATFORM_NEW_BLOCK_ALIGNMENT to 0.
Congratulations on the birth of your daughter.
The semantics of "here's the alignment that should be applied to a newly allocated block" versus "here's some details of how you'll be able to use custom memory management" seem very different to me. The fact that XMemory is the one and only user of the alignment function currently doesn't mean that we should assume it always will be. So _if_ we're to alter XMemory behavior, which we haven't proven is needed yet, I would definitely want a different way to specify that. I'll grant your statement that XML_PLATFORM_NEW_BLOCK_ALIGNMENT isn't document except in the header, and simply point out that there's much to Xerces platform porting that's documented nowhere but in the code.
(1) Understand the problem (2) Architect a solution
We haven't done (1) yet, and we're arguing about a (2) that has no purpose I can think of besides making things more complex.
James.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
