Problem in PlatformUtils::Initialize

[Bill Schindler <de...@bitranch.com>]

I was just looking at the XMLPlatformUtils::Initialize() code and noticed
that an XMLMutex is created before platformInit is called. Here's the first
few lines from Initialize():

--------------------
gInitFlag++;

if (gInitFlag > 1)
    return;
	
// Create the local sync mutex
gSyncMutex = new XMLMutex;

// Create the array for saving lazily allocated objects to be deleted at
termination
gLazyData= new RefVectorOf<XMLDeleter>(512);

platformInit();
--------------------

Shouldn't platformInit() be called first? I just did a fast search through
a few of the Platforms files and it looks like creating the XMLMutex first
(which calls the platform-specific mutex code) will fail on at least the
Macintosh.

(Besides, if we really could create a mutex that early in
XMLPlatformUtils::Initialize, why not make the method thread safe?)

It looks like the platformInit() call needs to move up before the mutex
creation. Since the rules are that platformInit may only call system
functions, there should be no need for the lazy data deallocator at the
point platformInit() is called.


--Bill

Re: Problem in PlatformUtils::Initialize

[Bill Schindler <de...@bitranch.com>]

> You are correct, sir. Don't know how long its been that way, probably
> forever. But its technically incorrect and could cause problems in the
> future

I don't see any place that the fix is going to break anything -- and it
will fix at least one platform.

I'll make the change and commit it. If anyone sees a side-effect on their
platform, yell!


--Bill

Re: Problem in PlatformUtils::Initialize

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

You are correct, sir. Don't know how long its been that way, probably
forever. But its technically incorrect and could cause problems in the
future.

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

"We're gonna need a bigger boat"


----- Original Message -----
From: "Bill Schindler" <de...@bitranch.com>
To: <xe...@xml.apache.org>
Sent: Tuesday, February 06, 2001 7:43 PM
Subject: Problem in PlatformUtils::Initialize


> I was just looking at the XMLPlatformUtils::Initialize() code and noticed
> that an XMLMutex is created before platformInit is called. Here's the
first
> few lines from Initialize():
>
> --------------------
> gInitFlag++;
>
> if (gInitFlag > 1)
>     return;
>
> // Create the local sync mutex
> gSyncMutex = new XMLMutex;
>
> // Create the array for saving lazily allocated objects to be deleted at
> termination
> gLazyData= new RefVectorOf<XMLDeleter>(512);
>
> platformInit();
> --------------------
>
> Shouldn't platformInit() be called first? I just did a fast search through
> a few of the Platforms files and it looks like creating the XMLMutex first
> (which calls the platform-specific mutex code) will fail on at least the
> Macintosh.
>
> (Besides, if we really could create a mutex that early in
> XMLPlatformUtils::Initialize, why not make the method thread safe?)
>
> It looks like the platformInit() call needs to move up before the mutex
> creation. Since the rules are that platformInit may only call system
> functions, there should be no need for the lazy data deallocator at the
> point platformInit() is called.
>
>
> --Bill
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>

Re: Problem in PlatformUtils::Initialize

[James Berry <jb...@criticalpath.com>]

Bill,

Good catch. I had actually always rather liked the philosophy that one
should be able to call the mutex routines even before platformInit had been
called (this has never been intentionally relied upon, that I know of), so
it's ironic that I'm the one who broke this (inside my Mac code).

Yes, the Mac code doesn't currently support creating a mutex before
platformInit is called (though it doesn't explicitly break either, which may
just be lucky). It's currently most liable to break at the point at which
gSyncMutex is destroyed.

I can change the Mac code to support this case. But I also buy your argument
that the creation of the gSyncMutex and the lazy data could/should just be
moved to after the call to platformInit.

The only good reason to support use of mutexes before platformInit would be,
as you suggest, to enable a truly thread-safe use of Initialize/Terminate.

Closure anyone?

-jdb

On 2/6/01 7:43 PM, "Bill Schindler" <de...@bitranch.com> wrote:

> I was just looking at the XMLPlatformUtils::Initialize() code and noticed
> that an XMLMutex is created before platformInit is called. Here's the first
> few lines from Initialize():
> 
> --------------------
> gInitFlag++;
> 
> if (gInitFlag > 1)
>   return;
> 
> // Create the local sync mutex
> gSyncMutex = new XMLMutex;
> 
> // Create the array for saving lazily allocated objects to be deleted at
> termination
> gLazyData= new RefVectorOf<XMLDeleter>(512);
> 
> platformInit();
> --------------------
> 
> Shouldn't platformInit() be called first? I just did a fast search through
> a few of the Platforms files and it looks like creating the XMLMutex first
> (which calls the platform-specific mutex code) will fail on at least the
> Macintosh.
> 
> (Besides, if we really could create a mutex that early in
> XMLPlatformUtils::Initialize, why not make the method thread safe?)
> 
> It looks like the platformInit() call needs to move up before the mutex
> creation. Since the rules are that platformInit may only call system
> functions, there should be no need for the lazy data deallocator at the
> point platformInit() is called.
> 
> 
> --Bill
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org

--
/**********************************
 James D. Berry
 mailto:jberry@criticalpath.com
 vox:503.265.1213 fax:503.222.3020
 **********************************/