1

I am creating a console program, which will have some resources like some threads and some sockets.

When the user closes the console program, should I detect this closing event and free those resources, or can I just let the OS handle this?

And do well known console programs (for example: ls, cat, grep in Linux) free their resources when they exit?

My question is not about a single OS (my console program will run on Windows and Linux and macOS).

Christopher
  • 729
  • 7
  • 12
  • Do you have a criteria in mind for should? A bias towards efficiency, portability, reliability or reusability might yield different answers. An overarching observation is that fclose(stdout) is almost unheard of. – mevets Jul 04 '19 at 13:53
  • What do you mean with "user closes the program"? Is this the natural end of the program or also e.g. the user typing CTRL+C or a kill command to close your program? The answer might be different for these cases. – slingeraap Jul 04 '19 at 13:59
  • Good code always cleans up after itself. – Ken White Jul 04 '19 at 14:02
  • Good code always shuts down immediately when instructed. – Martin James Jul 06 '19 at 07:42

4 Answers4

3

When the user closes the console program, should I detect this closing event and free those resources, or can I just let the OS handle this?

Good code is re-used. What today is "closes the console program", tomorrow could be "return from a function" called Christopher_console program().

Plan for re-use and close/free allocated resources.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
3

Both other answers (so Luke's one and chux' one) make sense. It is a matter of perspective.

But cleaning up your mess makes debugging easier with valgrind.

If your program is serious enough to need a lot of debugging, you may want to facilitate that. If you choose to avoid cleanup for performance reasons (e.g. Luke's approach), you might however have some rare --cleanup-the-mess program option which forces it (and tries hard to keep valgrind happy) ...

But if you write things conceptually similar in high-view behavior to (Linux programs like:) cron, bash, guile, make, xslt, tidy, indent, convert, etc, so a shell program, or any kind of interactive interpreter which you would run (in most cases) for only a few minutes, you could reasonably decide to take Luke's approach. On the other hand, if you write a program which runs for a long time (some specialized server for example), you definitely want to avoid every memory leak (and you need to use valgrind).

Community
  • 1
  • 1
Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • It does make 'valgrind' debugging easier, which is just as well, since the ever-growing shutdown/cleanup code will need test/debug/maintainance:( – Martin James Jul 06 '19 at 07:36
1

Generally it is not required, and it's faster to let the OS take care of it. From a brief look at GNU coreutils source, many programs will simply call die() when encountering an error which will exit the process immediately.

Luke McCarthy
  • 879
  • 2
  • 9
  • 21
  • 1
    *not required* does not mean you shouldn't do it anyway. Good coding habits are to always clean up after yourself. – Ken White Jul 04 '19 at 14:03
  • It depends on the kind of program. Any long running process of course should carefully manage it's resources, but for one-shot utilities all it does is make your program larger for no real benefit. – Luke McCarthy Jul 04 '19 at 14:06
  • 1
    Except *one shot* code almost always gets used again, either by you or someone else. And sloppy programming habits are a bad idea, whether it's in a *one shot* program or a long-term project. Garbage code is garbage code. This site is intended to help share knowledge, and part of doing so is to teach good lessons, not bad habits. – Ken White Jul 04 '19 at 14:07
  • But it is a matter of trade-offs, and sometimes cleanup the mess might need a lot of time. YMMV – Basile Starynkevitch Jul 04 '19 at 14:09
  • I used to have the same opinion years ago, but I changed my mind. I used the term "one shot" not referring to the project duration, but how the program is invoked, i.e. as a command-line process with definite input, process, output phases, as opposed to an process with an event loop. Programmers seem to spend a lot of time re-inventing parts of the operating system rather than taking advantage of already existing functionality (like process cleanup). – Luke McCarthy Jul 04 '19 at 14:17
  • Those proponents of 'always clean up' have never had to write, test, debug and maintain the shutdown of a complex, multithreaded system which is busy, and hence in an unknown state. Sure, clean up where you have to but, if you do not, let the OS do what your user code sensibly can not. – Martin James Jul 06 '19 at 07:30
0

In some systems there is a common c runtime, meaning that c programs share certain resources so a resource leak in one program can impact other applications. therefore it is essential that all applications release what is not in uses. There is a good discussion on the CRT here What is the C runtime library?

newbie
  • 558
  • 7
  • 12