ExampleDll *dll = LoadDll(L"bin\\example.dll");
IObject *obj = dll->CreateObject();
...
obj->Release();
delete dll;//fine because all objects already deleted
return 0;
auto_ptr<ExampleDll> dll = LoadDll(L"bin\\example.dll");
FlPtr<IObject> obj = dll->CreateObject();
...
return 0;//crash if dll is destructed before obj since Object::Release needs to call into the dll
Quote:Original post by Fire LancerGetModuleHandle(NULL) will always give you the handle of the EXE not the DLL, even if called from DLL code - that could well be your problem.
It then deletes itsself calling FreeLibrary(GetModuleHandle()) in its destructor.
This however crashes at the FreeLibrary, im asuming because the thread is still in the dlls code that is being unloaded...
Quote:Original post by Fire LancerObjects are destroyed in the reverse order they're created in, so if you have a function that declares a smart pointer to the DLL, then to an object in the DLL, then the object will be destroyed first, then the DLL mart pointer.
I'm at a loss now how to make sure the dll is only unloaded when there are no remaining objects, apart from going back to freeing the dll explicitly after everything else should have been deleted (meaning I cant use smart pointers for them either and alow for automatic destruction :( )
Is there some way to force instances of a certain object to be destroyed last when they go out of scope so that all the dlls objects are cleaned up before the dll is freed?
Quote:Original post by Fire LancerWhat do you mean poll the DLL? I'm not aware of COM doing anythung like this?
EDIT: Another suggetsion was to poll the dll every so often like COM does. How would I go about doing this without any major impact of proformance?
Also is there any diffrent approaches to this problem ive missed?
Quote:
Objects are destroyed in the reverse order they're created in, so if you have a function that declares a smart pointer to the DLL, then to an object in the DLL, then the object will be destroyed first, then the DLL mart pointer.
Quote:
What do you mean poll the DLL? I'm not aware of COM doing anythung like this?
Quote:
GetModuleHandle(NULL) will always give you the handle of the EXE not the DLL, even if called from DLL code - that could well be your problem.
Quote:Original post by Fire LancerFor globals, yes. This is another reason why globals are bad though [smile]
Isnt the order globals are destroyed undefined though?
Quote:Original post by Fire LancerInteresting, I wasn't aware of that (MSDN page for DllCanUnloadNow).
COM calls a function exported from the dll (CanUnloadNow I think) every now and then, if the method returns true then the dll is unloaded.
Quote:
To be honest, I think that's likely to be your best bet.
Alternatively, it may be better to modify your FlPtr class to call your DLL's version of DllCanUnloadNow() when it destroys an object. The overhead should be minimal, since destruction of an object isn't that common an operation.
So your saying check after every object is destroyed?
eg://FlPtr release code...HMODULE handle = ptr->GetDllHandle();if(!ptr->Release())//returns new ref count. 0 = deleted if(DllCanUnloadNow(handle)) FreeLibrary(handle);
Just how fast will that be? DllCanUnloadNow(handle) will somehow need to obtain a function pointer to the dlls DllCanUnloadNow() from the handle and then call it.
Are HMODULE handles constant if the dll is loaded multiple times, ie could a dll store the handle in a global so all its objects can return it?
Quote:Original post by Fire LancerNot really - the DLL has to be unloaded before the EXE ends, if it's not then the OS will unload the DLL as part of the EXE cleanup.Quote:
To be honest, I think that's likely to be your best bet.
The problem is I dont know what to call the function from, it cant be the main app since it needs to be able to unload the dll after the main app has finished. Could I somehow create a diffrent process and give it the handle for the dll(s) and make it loop slowly checking?
Quote:Original post by Fire LancerYep, that looks fine to me. If you call LoadLibrary() multiple times without calling FreeLibrary(), then the returned HMODULE will be the same. The problem comes when you load the DLL, unload it, then re-load it - then there's no guarantee that the HMODULE will be the same. However, since we're talking about the DLL being in memory through all of this, it'll be fine.Quote:
Alternatively, it may be better to modify your FlPtr class to call your DLL's version of DllCanUnloadNow() when it destroys an object. The overhead should be minimal, since destruction of an object isn't that common an operation.
So your saying check after every object is destroyed?
eg:
*** Source Snippet Removed ***
Just how fast will that be? DllCanUnloadNow(handle) will somehow need to obtain a function pointer to the dlls DllCanUnloadNow() from the handle and then call it.
Are HMODULE handles constant if the dll is loaded multiple times, ie could a dll store the handle in a global so all its objects can return it?
Quote:
Not really - the DLL has to be unloaded before the EXE ends, if it's not then the OS will unload the DLL as part of the EXE cleanup.
Quote:
You can just use GetProcAddress() to get the address of your DllCanUnloadNow() function from the HMODULE
Quote:Original post by Fire LancerYes.Quote:
Not really - the DLL has to be unloaded before the EXE ends, if it's not then the OS will unload the DLL as part of the EXE cleanup.
Is it garunteed to do this after clearing up any globals etc in the exe and not before?
Quote:Original post by Fire LancerI can't say for sure, I suspect it's a lookup table - LoadLibrary() on XP uses a lookup table internally to see if the library is loaded, and that's called far less frequently that GetProcAddress(). You could always use QueryPerformanceCounter() to check the time taken to call GetProcAddress().Quote:
You can just use GetProcAddress() to get the address of your DllCanUnloadNow() function from the HMODULE
Yes thats what I'm doing to get the object factory methods from the dll in the first place. The question is just how fast is getting the address? Is it a simple lookup in a table or does windows go searching though the dll looking from a function with that name (which is something I dont really want to do everytime an object is destroyed).
