Re: Initializing static C++ class variable in a HAL plugin
Re: Initializing static C++ class variable in a HAL plugin
- Subject: Re: Initializing static C++ class variable in a HAL plugin
- From: Doug Wyatt <email@hidden>
- Date: Thu, 3 Feb 2005 02:57:06 -0800
Global C++ objects with constructors can be problematic. We
scrupulously avoid them because our code gets loaded into many contexts
in which it does not end up being used, so the CPU and memory expense
of initialization ends up wasted.
You may need to find another way of initializing your globals. Globals
that aren't C++ objects are generally OK; it's just the constructors
that are problems.
I'm not familiar with the HAL plug-in API, but MyInitialize() looks
like it may be a good place to do this:
struct Foo {
Foo() {printf("Constructor called \n");}
static Foo *fInstance;
};
Foo *Foo::FInstance = NULL;
OSStatus MyInitialize(AudioHardwarePlugInRef inSelf)
{
if (Foo::fInstance == NULL)
Foo:fInstance = new Foo;
...
}
Doug
On Feb 3, 2005, at 1:21, Stéphane Letz wrote:
Message: 8
Date: Tue, 1 Feb 2005 12:11:50 -0800
From: Jeff Moore <email@hidden>
Subject: Re: Initializing static C++ class variable in a HAL plugin
To: CoreAudio API <email@hidden>
Message-ID: <email@hidden>
Content-Type: text/plain; charset="iso-8859-1"
I see. Yes, the first call your app makes to the HAL will load the
plug-in. It wasn't clear from your earlier postings that this was the
case.
At any rate, I'm not sure I understand what you are doing, so correct
me please:
1) You have an application that wants to use some kind of back channel
communication to talk to your HAL plug-in.
2) The back channel is statically initialized global variables in the
the plug-in's dyld.
My question is how does the app get access to the plug-in's globals?
Is
it linking against the plug-in, which exports the appropriate symbols?
It sounds like it to me, because I think that the problem you seeing
is
aliasing. Your app is getting your plug-in loaded twice. Once by the
loader when the process boots up and again by the HAL when it loads
the
bundle. Consequently, your app is seeing dead globals that aren't
actually getting initialized, whereas your plug-in is working fine
with
the correct set of globals.
The right way to communicate with a dynamically loaded bundle is via
CFBundle calls, CFPlugIn calls, or low-level dyld calls. However you
do
it, the app has to get ahold of the thing that the HAL loads, and then
dynamically load the symbols it needs (or interface if it uses
CFPlugIn).
On Feb 1, 2005, at 2:47 AM, Stéphane Letz wrote:
I'm not sure to fully understand the "aliasing" issue....
Let me explain the simplest case that shows the problem:
I have a userland HAL plug-ing that implement the AudioHardwarePlugIn
API.
The Initialize method does:
OSStatus MyInitialize(AudioHardwarePlugInRef inSelf)
{
printf("MyInitialize called\n");
......
}
Then the plug-in uses a C++ class that has some static variable like
the following in the .h file:
struct Foo {
Foo() {printf("Constructor called \n");}
static Foo fInstance;
};
The static variable is then defined in the .cpp file
Foo Foo::FInstance;
When I launch any CoreAudio application (iTunes.. QuikTimePlayer..) I
see the following
Constructor called
MyInitialize called
....
This the C++ static variable initialization is correctly done when the
plug-in is loaded by the HAL *before* the MyInitialize is called
.
Now if I use an application that uses the MTCoreAudio framework
(http://aldebaran.armory.com/~zenomt/macosx/MTCoreAudio/ with its
speical use of "load" method.)
like AudioMonitor included in the MTCoreAudio package, i get:
MyInitialize called
Constructor called
Thus C++ static variable initialization is called *after* the
MyInitialize method, and since MyInitialize need these static
variables, the plug-ins fails.
Any idea?
Stephane Letz
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden