Would it be acceptable practice to use the following function to free
memory resources before exit (for fatal errors)?
int G_set_error_routine();
Documentation indicates that it should be used to redirect text.
--
Brad Douglas <rez@touchofmadness.com>
Brad Douglas wrote:
Would it be acceptable practice to use the following function to free
memory resources before exit (for fatal errors)?
The OS automatically recovers the process' memory when the process
terminates.
If you want to perform specific tasks (e.g. deleting temporary files)
upon termination, use atexit().
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, 2005-03-21 at 23:08 +0000, Glynn Clements wrote:
Brad Douglas wrote:
> Would it be acceptable practice to use the following function to free
> memory resources before exit (for fatal errors)?The OS automatically recovers the process' memory when the process
terminates.
My copy of glibc would beg to differ (_MALLOC_CHECK environ variable).
Besides, it's just very bad practice not to explicitly free resources.
If you want to perform specific tasks (e.g. deleting temporary files)
upon termination, use atexit().
This is what I am doing at the moment. After I actually looked at the
code behind G_set_error_routine(), it became evident that it would not
work for my purposes.
It would be nice to have a virtual function for freeing resources upon
fatal error, though.
--
Brad Douglas <rez@touchofmadness.com>
Brad Douglas wrote:
> > Would it be acceptable practice to use the following function to free
> > memory resources before exit (for fatal errors)?
>
> The OS automatically recovers the process' memory when the process
> terminates.My copy of glibc would beg to differ (_MALLOC_CHECK environ variable).
1. Huh? What does _MALLOC_CHECK have to do with anything?
2. Your copy glibc is irrelevant. One a process has terminated, the
kernel will re-use its memory for other purposes. Nothing which the
program (or its libraries) does can affect this.
Besides, it's just very bad practice not to explicitly free resources.
Explicitly free()ing memory when you know that the process is about to
terminate is a waste of CPU cycles. free() simply re-arranges
user-space data structures, i.e. adding the memory block to the free
list. Upon termination, the process' memory is going to vanish, so
there is no point in rearranging it.
The only reason for explicitly free()ing memory on shutdown is if you
want to re-use the code in a context where shutdown doesn't imply
process termination, i.e. where you can "close" a library but the
process keeps running. In that situation, the saving in CPU cycles
isn't worth making the code more complex by having separate cleanup
routines for the two cases.
--
Glynn Clements <glynn@gclements.plus.com>
On Thu, 2005-03-24 at 20:18 +0000, Glynn Clements wrote:
> Besides, it's just very bad practice not to explicitly free resources.
Explicitly free()ing memory when you know that the process is about to
terminate is a waste of CPU cycles. free() simply re-arranges
user-space data structures, i.e. adding the memory block to the free
list. Upon termination, the process' memory is going to vanish, so
there is no point in rearranging it.
Bah. I've been in kernel-space far too long writing device drivers. I
take back everything I said. Now to go un-complicate my work...
--
Brad Douglas <rez@touchofmadness.com>