I could test this myself, but I would like to understand what will happen under the covers.
My application loads a number of COM objects at runtime. Which objects are loaded is entirely up to the user and the individual objects loaded have no knowledge of each other. The main application itself has no knowledge of fmod.
So, let’s say that two of the objects want to use fmod. Since they could both be loaded and they don’t know about each other, how should they handle the call to FSOUND_Init? The obvious answer is to have the main application call it once at start-up, but, as I stated, it has no idea these objects plan to use fmod.
Thanks in advance,
- pablop asked 14 years ago
I think that for different modules the best way would be to go for the fmoddyn.h approach I think.
If not then you will need some kind of global variables, so that you can count how many objects want to use fmod.
If the value is 0, then the object that wants to use it initializes it.
If it is greater, the objects just increment the counter.
At destruction, each object decrements the counter, and when the counter is 0 that object has to call FSOUND_Close as well.
- Adion answered 14 years ago
I’ve tried the fmoddyn approach with no luck…I used the Delphi version of this and it does not seem to work correctly.
In principle, I don’t see how it could work. Even if two different modules load the library individually, they will both point to the same code…the first one that calls FSOUND_Close will ruin it for the other one.
Windows does not load the same library twice; if LoadLibrary is called again for a library with the same path, the same handle is returned.
The only remaining trick I can see is to use multiple copies of the fmod dll each with a different file name, but that seems like a very gross hack. Let me re-iterate that a global variable is not an option in my case….I have multiple COM objects using fmod and they know nothing about each other.
It seems to me that fmod should do one of two things:
- Use reference counting to prevent multiple invocations to Init and Close from stepping on each other.
Drawback of this is that you can only have a single instance of fmod and it can only be initialized once with a single set of parameters.
- Use a context variable that contains all the global state for fmod. This would be returned by a new function.
The good thing here is that you can have as many instances of the fmod engine as you want. The drawback is that you have to pass the context variable to every subsequent call.
This is the approach most commonly used in these types of libraries.
I don’t think it is pointless. As you can see, in this case, it is not feasable for me to have a global flag. And, fmod already has that global flag – I assume that it knows it has been initialized already.
And, the code would be simple:
If the NO_REINIT flag is present and i’ve already been initialized, then do nothing and return a success code.
And what about quitting? If YOUR application is quitting do you want to tell fmod that it must not ‘close’ when it was initalized twice and it’s the first unload command? You’ll have to know which threads (…) are using fmod to ensure no thread uses functions after closing fmod, or your application will properly crash.
Please login first to submit.