Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Cleanup before termination?

This question has been bugging me for a while: I've read in MSDN's DirectX article the following:

The destructor (of the application) should release any (Direct2D) interfaces stored...

DemoApp::~DemoApp()
{
    SafeRelease(&m_pDirect2dFactory);
    SafeRelease(&m_pRenderTarget);
    SafeRelease(&m_pLightSlateGrayBrush);
    SafeRelease(&m_pCornflowerBlueBrush);
}

Now, if all of the application's data is getting released/deallocated at the termination (source) why would I go through the trouble to make a function in-order-to/and release them individually? it makes no sense!

I keep seeing this more and more over the time, and it's obviously really bugging me. The MSDN article above is the first time I've encountered this, so it made sense to mention it of all other cases.

Well, since so far I didn't actually ask my questions, here they are:

  • Do I need to release something before termination? (do explain why please)
  • Why did the author in MSDN haven chosen to do that?
  • Does the answer differ from native & managed code? I.E. Do I need to make sure everything's disposed at the end of the program while I'm writing a C# program? (I don't know about Java but if disposal exists there I'm sure other members would appreciate an answer for that too).

Thank you!

like image 666
MasterMastic Avatar asked Nov 16 '12 18:11

MasterMastic


People also ask

Which standard library function can be used to call clean up tasks?

The exit subroutine terminates the calling process after calling the standard I/O library _cleanup function to flush any buffered output. Also, it calls any functions registered previously for the process by the atexit subroutine.

What is Atexit?

The atexit module defines functions to register and unregister cleanup functions. Functions thus registered are automatically executed upon normal interpreter termination.


1 Answers

You don't need to worry about managed content when your application is terminating. When the entire process's memory is torn down all of that goes with it.

What matters is unmanaged resources.

If you have a lock on a file and the managed wrapper for the file handler is taken down when the application closes without you ever releasing the lock, you've now thrown away the only key that would allow access to the file.

If you have an internal buffer (say for logging errors) you may want to flush it before the application terminates. Not doing so would potentially mean the fatal error that caused the application to end isn't logged. That could be...bad.

If you have network connections open you'll want to close them. If you don't then the OS likely won't do it for you (at least not for a while; eventually it might notice the inactivity) and that's rather rude to whoever's on the other end. They may be continuing to listen for a response, or continuing to send you information, not knowing that you're not there anymore.

like image 61
Servy Avatar answered Sep 21 '22 03:09

Servy