Internally we've made a set of changes to attempt to get around this
problem as well.
The first part of the change was to change the XMLDeleterFor to take a
reference, which after deleting the field, sets it to NULL. This
involved changing anyone who use the DeleterFor to pass the address of
the pointer. This fixed most of the cases, with the other one being the
gScannerMutex. (Maybe some folks here can tell me how valid or invalid
my change is).
Within the if (XMLPlatformUtils::compareAndSwap(...) )
We just return *scannerMutex(at the end, after deleting the tmpMutex),
the belief being that the scanner mutex is valid, so just return it.
As a result, we ditched the registered flag, since only one thing should
be able to get through the path and register the scannerMutex for
deleter. Since then, we've been able to call Init/Terminate as many
times as we want without any problems.
Looking back over the change, I might have introduced a multi-threading
problem since we don't ever lock the scanner mutex(which might be the
whole reason it's around). Ugh. We've probably gotten away with it
since we don't do that many parses, and at least the init and term calls
are reference counted and multi-thread safe due to some changes we've
made outside the library.
So have I seriously screwed up the gscannerMutex? And if so, any ideas
on how to fix it and still keep the rest of the changes the same?
Later,
Casey Schmit
[EMAIL PROTECTED]
-----Original Message-----
From: Jesse Pelton [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 07, 2001 10:55 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Problem initializing and terminating XMLPlatformUtils
I'm glad you've managed to join the list, Mark.
The basic approach seems to me a good one. There are a couple of
implementation details that may or may not need discussion.
First, this approach uses a linked list, where the current XMLDeleter
model
uses a RefVector. A linked list seems likely to be simple and efficient,
but
maybe there's a compelling reason to use a vector that I'm unaware of.
Second, I think that the XMLRegisterCleanup objects should be dynamic
rather
than static. The XMLDeleter model makes sense to me: when you perform
some
initialization (presumably lazy initialization of global data), you
create
and register the corresponding cleanup object. Terminate() then does the
cleanup and deletes each cleanup object. The main advantage to this is
that
you call only the required cleanup functions, which can assume that the
corresponding initialization has occurred. Using the static list, all
cleanup functions will always be called, even if the corresponding
initialization never took place. Furthermore, there may be construction
order problems with the static list. The outlined code assumes that
gXMLCleanupList is initialized to NULL somewhere before the
XMLRegisterCleanup constructor is called for the first time. I'm not
sure
you can guarantee this happens in the required order.
-jesse-
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
