View previous topic :: View next topic |
Author |
Message |
ponce
Joined: 12 Nov 2009 Posts: 55
|
Posted: Tue Oct 18, 2011 5:43 pm Post subject: SDL DLL gets unloaded before SDL_Quit is called. |
|
|
Hi Aldacron,
Not sure if you would consider this as a problem.
I'm used to make resource wrappers for everything and let the GC do the cleanup at the program exit. Ownership gets way easier like this, each class object has a reference (indirect or not) on everything it needs to exist.
As an exemple, the SDL library is wrapped in a class which calls DerelictSDL.load, SDL_Init and SDL_Quit. It's destroyed by a GC cycle when no longer referenced, and every one of my object which need SDL to be loaded will refer to an instance of it. I prefer this over singletons.
Problem: DerelictSDL.unload() is called in a module destructor before the GC clean up my wrapper object. When SDL_Quit() is called the memory does not contain the DLL anymore.
There are 3 possible resolutions :
- comment the line calling DerelictSDL.unload() in the static destructor (current solution in my local copy)
- do not call SDl_Quit, and trust the library (this seems to work too)
- use "delete" on my wrapper object explicitely before static destructors. This breaks my "GC cleans all" strategy as I need to guarantee further destructor ordering.
- putting my SDL_Quit calls themselves in static destructors and rely on guaranteed ordering
- instantiate a DerelictSDL myself in the wrapper object
Have you considered that the user could be responsible for creating and reference Derelict loaders? This could be a way to have no such trickery going on.
Not that it's a big deal or anything... it's a really small problem.
It's just one I did ran into the issue several times and understands it only now. _________________ @p0unce | gamesfrommars |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Wed Oct 19, 2011 8:32 pm Post subject: |
|
|
Initially, I put the static destructors in because I thought it would be more convenient. But over the years, I've seen this issue come up now and again. Rather than remove it, though, I think I'll make it optional. If you don't want automatic unload, it can be turned off. I'm planning a run of work on Derelict some time in the next couple of weeks. I'll see about adding something then. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
ponce
Joined: 12 Nov 2009 Posts: 55
|
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Sun Nov 06, 2011 2:42 am Post subject: |
|
|
I've just updated the Derelict 2 branch with this new feature. It's an all-or-nothing deal -- no picking which ones to handle manually.
Code: |
import derelict.util.loader;
SharedLibLoader.disableAutoUnload();
|
Once you call that method, you are responsible for unloading yourself any shared libs you have loaded. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
ponce
Joined: 12 Nov 2009 Posts: 55
|
Posted: Mon Nov 07, 2011 3:05 pm Post subject: |
|
|
Works great. Thanks ! _________________ @p0unce | gamesfrommars |
|
Back to top |
|
|
ponce
Joined: 12 Nov 2009 Posts: 55
|
Posted: Sat Jun 23, 2012 12:32 pm Post subject: |
|
|
(bump)
It seems to me that disableAutoUnload() should not be shared across all loaders.
It might create problems when mixing wrapper codes based on Derelict.
Do you want such a patch? _________________ @p0unce | gamesfrommars |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Sat Jun 23, 2012 7:23 pm Post subject: |
|
|
ponce wrote: | (bump)
It seems to me that disableAutoUnload() should not be shared across all loaders.
It might create problems when mixing wrapper codes based on Derelict.
|
I don't understand. What are wrapper codes?
My reasoning at the time was that if you want to manually unload one lib, you'll most likely want to manually unload all the libs you are using. It might be a little annoying to have to set it for each lib. I don't have a problem with doing it that way, though, if it's a better approach. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
ponce
Joined: 12 Nov 2009 Posts: 55
|
Posted: Sun Jun 24, 2012 1:14 pm Post subject: |
|
|
I'll be more explicit:
The problem I see - if I use library A which uses a Derelict loader together with lib B which uses another one, they will need to agree on how unloading should work.
But now that I read again my original message, I think my problem was not that module destructors were called before the wrapper object destructor. The problem was me relying on D class destructors to clean up resources, something that I've since learned not to do.
So now I think disableAutoUnload should be removed , provided unload can be called twice. _________________ @p0unce | gamesfrommars |
|
Back to top |
|
|
aldacron
Joined: 05 May 2004 Posts: 1322 Location: Seoul, South Korea
|
Posted: Sun Jun 24, 2012 10:09 pm Post subject: |
|
|
ponce wrote: | So now I think disableAutoUnload should be removed , provided unload can be called twice. |
The scenario you describe is something I hadn't considered. Furthermore, given that the unload method is publicly accessible anyway, I would need to hide that as well to be completely safe. Otherwise, the same issue can pop up. But then that removes the ability to do hot swapping. Hmmm.
EDIT: Unless I add ref-counting. So, remove disableAutoUnload and add ref-counting so that unload can be called multiple times. _________________ The One With D | The One With Aldacron | D Bits |
|
Back to top |
|
|
|