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: Stéphane Letz <email@hidden>
- Date: Thu, 3 Feb 2005 10:21:09 +0100
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( 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