Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Initializing static C++ class variable in a HAL plugin

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:
http://lists.apple.com/mailman/options/coreaudio-api/email@hidden

This email sent to email@hidden


Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.