FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

SDL DLL gets unloaded before SDL_Quit is called.

 
Post new topic   Reply to topic     Forum Index -> Derelict
View previous topic :: View next topic  
Author Message
ponce



Joined: 12 Nov 2009
Posts: 55

PostPosted: Tue Oct 18, 2011 5:43 pm    Post subject: SDL DLL gets unloaded before SDL_Quit is called. Reply with quote

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. Razz
_________________
@p0unce | gamesfrommars
Back to top
View user's profile Send private message Visit poster's website
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Wed Oct 19, 2011 8:32 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
ponce



Joined: 12 Nov 2009
Posts: 55

PostPosted: Thu Oct 20, 2011 1:01 pm    Post subject: Reply with quote

Great!
_________________
@p0unce | gamesfrommars
Back to top
View user's profile Send private message Visit poster's website
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sun Nov 06, 2011 2:42 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
ponce



Joined: 12 Nov 2009
Posts: 55

PostPosted: Mon Nov 07, 2011 3:05 pm    Post subject: Reply with quote

Works great. Thanks !
_________________
@p0unce | gamesfrommars
Back to top
View user's profile Send private message Visit poster's website
ponce



Joined: 12 Nov 2009
Posts: 55

PostPosted: Sat Jun 23, 2012 12:32 pm    Post subject: Reply with quote

(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
View user's profile Send private message Visit poster's website
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sat Jun 23, 2012 7:23 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
ponce



Joined: 12 Nov 2009
Posts: 55

PostPosted: Sun Jun 24, 2012 1:14 pm    Post subject: Reply with quote

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 Smile, provided unload can be called twice.
_________________
@p0unce | gamesfrommars
Back to top
View user's profile Send private message Visit poster's website
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sun Jun 24, 2012 10:09 pm    Post subject: Reply with quote

ponce wrote:
So now I think disableAutoUnload should be removed Smile, 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
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Derelict All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group