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: Jeff Moore <email@hidden>
- Date: Thu, 3 Feb 2005 12:43:48 -0800
I just read more about this ObjC +load method. Apparently it executes
in a special context that has lots of rules about what you can and
can't do, including restrictions on what functions you can call and
what objects you can touch. Judging from your experience, I imagine
that it is also executing before any C++ static initializers have run
which makes what you are trying to do pretty much impossible. You'll
need to defer the work until after +load finishes executing.
On Feb 3, 2005, at 1:21 AM, 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
--
Jeff Moore
Core Audio
Apple
_______________________________________________
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