Re: RE: RE: Re: memory leaks in XMLPlatformUtils::Initialize() (v.1.0 .1)

[Mu...@GDM.DE]

Dave wrote:
> I had to do this cross platform as well.  I created a small class which
called them
> in the constructor/destructor, and then created a static instance.  I
know this can
> have static initialisation order problems, but I know my app will only
use Xerces
> after main(), so I went this way

I avoid all static data in libraries because I imagine that it would lead
to multi-threading problems. Are there any multi-threading experts who can
say whether this idea of a static initialisation/termination object is a
good solution? Presumably the relevant bits in Xerces are locked, but is
that enough?

Murray Cumming
murrayc@usa.net
www.murrayc.com

Re: memory leaks in XMLPlatformUtils::Initialize() (v.1.0 .1)

[Arundhati Bhowmick <ar...@hyperreal.org>]

Do you still get it in ver 1.2.0?

David Crowley wrote:

> ----- Original Message -----
> From: "Arundhati Bhowmick" <ar...@hyperreal.org>
> To: <xe...@xml.apache.org>
> Sent: Tuesday, July 25, 2000 11:10 AM
> Subject: Re: memory leaks in XMLPlatformUtils::Initialize() (v.1.0 .1)
> .
> .
> .
> > to be there then you may as well deinitialize the xerces static data. This
> was
> > written after lot of false alarms on memory leak that people see through
> > various leak-detectors.
>
> Actually, it's not a false alarm.  It's really a leak.  Our application has
> a COM DLL linking to the Xerces lib.  MTS/COM+ can load and unload DLLs
> whenever it decides.  Everytime our DLL was unloaded, the Xerces lib leaked.
> And they were real.  It's not fluff.  It's needed functionality.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

Re: memory leaks in XMLPlatformUtils::Initialize() (v.1.0 .1)

[David Crowley <dc...@san.rr.com>]

----- Original Message -----
From: "Arundhati Bhowmick" <ar...@hyperreal.org>
To: <xe...@xml.apache.org>
Sent: Tuesday, July 25, 2000 11:10 AM
Subject: Re: memory leaks in XMLPlatformUtils::Initialize() (v.1.0 .1)
.
.
.
> to be there then you may as well deinitialize the xerces static data. This
was
> written after lot of false alarms on memory leak that people see through
> various leak-detectors.


Actually, it's not a false alarm.  It's really a leak.  Our application has
a COM DLL linking to the Xerces lib.  MTS/COM+ can load and unload DLLs
whenever it decides.  Everytime our DLL was unloaded, the Xerces lib leaked.
And they were real.  It's not fluff.  It's needed functionality.

Re: memory leaks in XMLPlatformUtils::Initialize() (v.1.0 .1)

[Arundhati Bhowmick <ar...@hyperreal.org>]

Yes, terminate() is an optional usage. Both initialize() and terminate() work
on static data initialized in xerces. If you call initialize() in your
application the data automatically gets deinitialized on exit of your
application. In case your application is loading and unloading the xerces
library pretty often then the terminate would be useful. Also in the case when
you want other processes in your application to carry on and don't want xerces
to be there then you may as well deinitialize the xerces static data. This was
written after lot of false alarms on memory leak that people see through
various leak-detectors.
Normally static init/exit is done outside the threading processes. As Jesse
mentioned you may use reference counting to handle it. There's a Threadtest in
<xerces>/tests that might give a glimpse of multi-threading mechanism with
xerces.

Arundhati

Murray.Cumming@GDM.DE wrote:

> Dave wrote:
> > I had to do this cross platform as well.  I created a small class which
> called them
> > in the constructor/destructor, and then created a static instance.  I
> know this can
> > have static initialisation order problems, but I know my app will only
> use Xerces
> > after main(), so I went this way
>
> I avoid all static data in libraries because I imagine that it would lead
> to multi-threading problems. Are there any multi-threading experts who can
> say whether this idea of a static initialisation/termination object is a
> good solution? Presumably the relevant bits in Xerces are locked, but is
> that enough?
>
> Murray Cumming
> murrayc@usa.net
> www.murrayc.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

Re: RE: RE: Re: memory leaks in XMLPlatformUtils::Initialize() (v.1.0 .1)

[Dean Roddey <dr...@charmedquark.com>]

All of the static stuff is protected, however, we do assume that you call
init/term within a single threaded situation, i.e. during process startup
and shutdown.

--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"You young, and you gotcha health. Whatchoo wanna job fer?"


----- Original Message -----
From: <Mu...@GDM.DE>
To: <xe...@xml.apache.org>
Sent: Tuesday, July 25, 2000 2:26 AM
Subject: Re: RE: RE: Re: memory leaks in XMLPlatformUtils::Initialize()
(v.1.0 .1)


>
>
>
> Dave wrote:
> > I had to do this cross platform as well. I created a small class which
> called them
> > in the constructor/destructor, and then created a static instance. I
> know this can
> > have static initialisation order problems, but I know my app will only
> use Xerces
> > after main(), so I went this way
>
> I avoid all static data in libraries because I imagine that it would lead
> to multi-threading problems. Are there any multi-threading experts who can
> say whether this idea of a static initialisation/termination object is a
> good solution? Presumably the relevant bits in Xerces are locked, but is
> that enough?
>
> Murray Cumming
> murrayc@usa.net
> www.murrayc.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>