RE: Initialize()/Terminate() redux

[Jesse Pelton <js...@PKC.com>]

Whaddya say, Andy? Are you willing to do the upkeep? Based on the current
code, the job doesn't seem onerous. Presumably, new code is often modelled
on existing code, so the model will tend to propagate once established.

I'm happy to do the initial work. Of the possibilities I outlined, I like
the idea of functions that allocate or set static data registering static
cleanup functions to be called from Terminate(). No one other than Dean has
offered any feedback, so I assume there are no objections.

> -----Original Message-----
> From: Dean Roddey [mailto:droddey@charmedquark.com]
> Sent: Wednesday, August 30, 2000 9:39 PM
> To: xerces-c-dev@xml.apache.org
> Subject: Re: Initialize()/Terminate() redux
> 
> 
> I don't have any better answer myself. If no one else 
> complains, and Andy H
> is willing to accept the burden of keeping up with these 
> types of issues
> over time, then I'd say go for it.
> 
> --------------------------
> Dean Roddey
> The CIDLib C++ Frameworks
> Charmed Quark Software
> droddey@charmedquark.com
> http://www.charmedquark.com
> 
> "It takes two buttocks to make friction"
>     - African Proverb
> 
> 
> ----- Original Message -----
> From: "Jesse Pelton" <js...@PKC.com>
> To: <xe...@xml.apache.org>
> Sent: Wednesday, August 30, 2000 1:10 PM
> Subject: RE: Initialize()/Terminate() redux
> 
> 
> > Is there a reason *not* to put in the patch I supplied?  It 
> might or might
> > not be completely rigorous, but it works for me, and based 
> on prior posts,
> I
> > think it would be useful for others.
> >
> > I spent a couple of hours reviewing use of static data in Xerces.  I
> believe
> > that, with my patch, almost everything is correct.  There 
> are, however, 21
> > instances where I didn't think (or wasn't sure) that things 
> were quite
> > kosher.  In some cases, it appears that there are memory 
> leaks that could
> > stand to be cleaned up.  There's only one case (#11) that 
> looks serious,
> > platform-independent, and somewhat difficult.  This could 
> be addressed by
> > creating an XMLResetterFor<T> template like 
> XMLDeleterFor<T> that would
> > simply set a datum to 0.  (There's gotta be a better name 
> for it, though.)
> > Terminate() would loop through a global list of data to be 
> reset, as it
> does
> > for data to be deallocated.  My changes to XMLDeleterFor<T> 
> would probably
> > be rendered unnecessary.
> >
> > Another approach is to provide for registration of (static) cleanup
> > functions that can do whatever they deem necessary.  Being 
> most flexible,
> > this might be best.
> >
> > Well, I think I've answered my initial question.  One good 
> reason not to
> > apply my patch is that there may be better solutions.  I'm 
> happy to tilt
> at
> > any of these windmills, given a little support and 
> direction from those
> > older (at least where Xerces is concerned) and wiser.  I am 
> anxious to get
> a
> > good solution implemented.
> >
> > Herewith the list of questionable or problematic uses of 
> static data:
> >
> > 1) src\com\XMLDOMUtil.cpp: m_pool is a static template 
> member.  The code
> is
> > complex, and I didn't try to analyze it.  I'm disinclined 
> to worry about
> it,
> > since I think it's a COM wrapper around the Xerces library, 
> and it's the
> > library that has the problem.
> >
> > 2) src\dom\DOMString.hpp: gLiveStringHandleCount could 
> conceivably be a
> > problem in an ill-behaved app, because DOMStringTerminate() 
> won't get
> called
> > unless the count goes to zero.  It's not obvious to me what kind of
> > misbehavior would cause this, or what an appropriate 
> response might be.
> >
> > 3) src\dom\DOMString.hpp: gLiveStringDataCount likewise 
> might not go to
> > zero.  It exists solely for the benefit of DomMemDebug.
> >
> > 4, 5) src\dom\DOMString.hpp: gTotalStringHandleCount and
> > gTotalStringDataCount are always incremented, never 
> decremented, and exist
> > only for the benefit of DomMemDebug.  It's unclear to me 
> whether they
> should
> > be cleared in Terminate().
> >
> > 6) src\dom\NamedNodeMapImpl.hpp: gLiveNamedNodeMaps - like
> > gLiveStringDataCount.
> >
> > 7) src\dom\NamedNodeMapImpl.hpp: gTotalNamedNodeMaps - like
> > gTotalStringHandleCount and gTotalStringDataCount.
> >
> > 8) src\dom\NodeImpl.hpp: gLiveNodeImpls - like gLiveStringDataCount.
> >
> > 9) src\dom\NodeImpl.hpp: gTotalNodeImpls - like 
> gTotalStringHandleCount
> and
> > gTotalStringDataCount.
> >
> > 10) src\internal\XMLScanner.cpp: gScannerId - incremented but never
> > decremented.  Might be nice to reset to  zero on 
> termination, but harmless
> > not to (I think).
> >
> > 11) src\internal\XMLScanner.cpp: registered is set true 
> when a scanner
> mutex
> > is first allocated.  The mutex gets deallocated during 
> termination, but
> > registered remains true.  This is the most serious example 
> of the problem
> > you describe.
> >
> > 12, 13, 14, 15) src\util\Platforms\HPUX\HPPlatformUtils.cpp,
> > src\util\Platforms\IRIX\IRIXPlatformUtils.cpp,
> > src\util\Platforms\Linux\LinuxPlatformUtils.cpp,
> > src\util\Platforms\UnixWare\UnixWarePlatformUtils.cpp: 
> atomicOpsMutex gets
> a
> > mutex allocated but never released.  Presumably could be 
> cleaned up in
> > platformTerm().
> >
> > 16, 17, 18) src\util\Platforms\OS400\OS400PlatformUtils.cpp,
> > src\util\Platforms\Solaris\SolarisPlatformUtils.cpp,
> > src\util\Platforms\Tru64\Tru64PlatformUtils.cpp: gAtomicOpMutex is
> allocated
> > but never released.  Presumably could be cleaned up in 
> platformTerm().
> >
> > 19) src\util\Transcoders\Iconv400\iconv_util.c: 
> _defaultConverter gets
> > opened but never closed.  This code is, umm, not up to the 
> usual Xerces
> > standards, and I have no idea how to fix it.
> >
> > 20) src\util\Transcoders\Iconv400\iconv_util.c: gErr 
> appears to get set
> > (when it's passed by reference to a function) but never 
> used.  It's not
> > clear whether its value is of any significance.  Whether 
> anything needs to
> > be done, or how, is unclear.
> >
> > 21) src\util\Transcoders\Iconv400\iconv_util.c: 
> DEFAULT_CONVERTER_NAME
> gets
> > initialized with strcpy() and never modified thereafter; 
> I'm not sure why
> > it's not initialized when declared and made const.  (There 
> are a fair
> number
> > of other instances where it appears that data could be 
> const, but isn't.)
> >
> > > -----Original Message-----
> > > From: Dean Roddey [mailto:droddey@charmedquark.com]
> > > Sent: Friday, August 25, 2000 11:20 PM
> > > To: xerces-c-dev@xml.apache.org
> > > Subject: Re: Initialize()/Terminate() redux
> > >
> > >
> > > The big issue if there is some place where things are faulted
> > > in that are
> > > not directly pointers, i.e. you call Init() on some object,
> > > or there is a
> > > boolean flag used to control initialization of a block of
> > > data (which aren't
> > > necessarily allocated data just set to values which are
> > > changed over time),
> > > etc... You have to have some way to always know that you are
> > > getting any
> > > such data back to where it was to begin with. Its not that it
> > > couldn't be
> > > done once with an intensive SWAT. But keeping it that way,
> > > and being sure
> > > that it is being kept up to date could be a mess over time.
> > >
> > > --------------------------
> > > Dean Roddey
> > > The CIDLib C++ Frameworks
> > > Charmed Quark Software
> > > droddey@charmedquark.com
> > > http://www.charmedquark.com
> > >
> > > "It takes two buttocks to make friction"
> > >     - African Proverb
> > >
> > >
> > > ----- Original Message -----
> > > From: "Jesse Pelton" <js...@PKC.com>
> > > To: <xe...@xml.apache.org>
> > > Sent: Friday, August 25, 2000 7:36 AM
> > > Subject: Initialize()/Terminate() redux
> > >
> > >
> > > > The issue of being able to Initialize() after Terminate()
> > > keeps coming up
> > > in
> > > > our work.  The primary reason: we're developing COM
> > > objects, several of
> > > > which may live in a single DLL.  Not all such objects need
> > > Xerces, so
> > > rather
> > > > than initializing and terminating the library when the DLL
> > > is loaded and
> > > > unloaded, we'd like to do so when a given object is 
> activated and
> > > > deactivated.  These functions are currently designed for
> > > process-level
> > > > initialization and cleanup, which is inadequate for our 
> purposes.
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> > For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>