Untitled

Published October 09, 2008
Advertisement
Antheus posted a pretty interesting article today (the "automatic destructors" bit, I couldn't give a monkeys about memory mapped files). Someone said in a thread the other day about consoles sometimes doing cold shutdown to save all the time of manually releasing resources that would just get reclaimed anyway, but I hadn't really thought about this in terms of PCs.

Given that pretty much all modern versions of Windows will now reclaim memory, GDI objects, file handles etc, should we really be manually releasing application-wide stuff at exit any more?

One problem I do see is that I understand some buggy graphics card drivers can fail to release video memory for textures, vbs etc unless they are manually released by the calling application. I'd assume this problem could also apply to other plug-in hardware - soundcard drivers, printer drivers etc.

But for purely OS-based resources, is the "let the kernel do it" approach now better than manually releasing them yourselves?

Rhetorical question, but would be interested to know what people think.
0 likes 5 comments

Comments

Evil Steve
Yeah, I saw that. Personally, I think it's bollocks [smile]. It's relying on the OS to clean up, and relying on other systems to do things you should do yourself seems like a really bad idea to me.

Add to that the fact that you'd need to write the code if you're running on Win9x where it's possible to leak handles and cause explorer to do Weird Things, and it just seems pointless to me.

It's not like it'll take 30 seconds to shutdown your app; the author says it took 20 minutes to reboot his system - that really says it all. If the PC is that slow, it doesn't matter what you do really.
October 10, 2008 05:34 AM
Aardvajk
Quote: Original post by Evil Steve
Yeah, I saw that. Personally, I think it's bollocks [smile]. It's relying on the OS to clean up, and relying on other systems to do things you should do yourself seems like a really bad idea to me.

Add to that the fact that you'd need to write the code if you're running on Win9x where it's possible to leak handles and cause explorer to do Weird Things, and it just seems pointless to me.

It's not like it'll take 30 seconds to shutdown your app; the author says it took 20 minutes to reboot his system - that really says it all. If the PC is that slow, it doesn't matter what you do really.


Very good points. I must admit I kind of felt like there was something fundamentally wrong with taking this approach, but I thought I'd be open minded, hence the desire for a discussion.

Just goes to show - just because someone has a lot of ability to write coherently and clearly a lot of technical expertise, doesn't mean they are right.

Plus, I think there are arguments to say this gets you into bad habits. Whenever I end up writing anything using GDI, I've got into the habit of running Task Manager with the GDI Objects column visible.

I've yet to write any GDI code first time round that doesn't leak resources, in the sense of while the program is running rather than at shutdown. It's only the fact that I am daft enough to check that I ever find out that if my program ran for (whatever, years? days?) all would go horribly wrong.

Sod console developers. We'll stay responsible [smile]
October 10, 2008 12:59 PM
Jotaf
Well, couldn't you just have a "fast shutdown" option and leave that choice up to the user? Now, if you think it's gonna be safe most of the time, it could be on by default, or you could go the safe route of leaving it off by default. It's just a couple of lines of code anyway (ie., if (fast_shutdown) exit(0); ).
October 13, 2008 11:27 AM
Anon Mike
Strangly, most users don't like having 30 billion options confusing them. Besides, if you were faced with the option of "fast shutdown" vs not, which would you pick? Of course you'd pick the fast one, then joke to your buddies about how stupid the nerds making the software are for having a "slow shutdown" option. Either that or you'd freeze up, call your nerd friend, and ask them if your computer would blow up if you picked the fast one.

But as to the main topic, one of the problems with having such a fast shutdown route is that it can make it difficult to track if you leaked resources. A lot of fancy resource managers will spit out a report of leaked objects at app shutdown and if you go bypassing things you'll get false reports. A good compromise might be to have such a fast exit (and turn off any reporting) unless it's a debug build of the app.
October 14, 2008 04:19 PM
Jotaf
Right, but it's not for the developer, it's for the user. Of course the developer should turn it off if the memory manager doesn't like it. And it's not at all as you describe it -- the idea is that it would be on by default, and the player wouldn't bother about it. Would you really turn off "fast shutdown" if a game was working just fine? No, but you would try it if you ran into problems, and started digging the Advanced Settings panel. It's a nice feature, easy to implement and with some clear advantages.
October 14, 2008 09:58 PM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement