Re: Newbie question on malloc()

["Paul Gimpelj" <pgimpelj@sympatico.ca>]

hi,
pardon me for patching to this thread,

but, following this conversation,
if files are left open at exit, does the operating system (linux) flush the
i/o buffers to disk before closing files?
This is not the case with windows 95/98  and dos.
OR, does the _exit() function in the c runtime do it.
Thanks.

thanks

regards,
Paul


----- Original Message -----
From: "John T. Williams" <jowillia@vt.edu>
To: "Glynn Clements" <glynn.clements@virgin.net>
Cc: "Micha Feigin" <michf@post.tau.ac.il>; "linux-c-programming"
<linux-c-programming@vger.kernel.org>
Sent: Thursday, June 03, 2004 6:25 PM
Subject: Re: Newbie question on malloc()


>
> I think this is may be a somewhat misleading statement. Not freeing
> memory before normal termination decreases re-usability of your code.
> You never know when your main function might be reused verbatim as
> another sub function. Failing to free memory before all reference leave
> scope can lead to massive memory leeks. Further, the more memory your
> program is holding at any given moment of operation the more pages it
> holds, the more pages it holds the more likely any particular call to a
> memory location will lead to a page fault, and page faults are
> expensive. Freeing memory allows malloc to reassign that memory next
> time its called. Now I know that this was a question about freeing
> memory before termination, and therefore unless we are talking about a
> situation where your code is being reused my last two arguments hold no
> weight, but I believe that it is simply good practice to always be aware
> of memory you have dynamically allocated and always free it after you no
> more use for it. In this way you don't get used to saying well if I miss
> it the operating system will clean it up for me. Please note I do not
> suggest that one should go to out of the way to free memory on abnormal
> termination, but its simply good practice to free memory when it is no
> longer being used in the normal behavior of your code.
>
>
>
> On Thu, 2004-06-03 at 03:59, Glynn Clements wrote:
> > Micha Feigin wrote:
> >
> > > > I have made a daemon in which dynamic memory is gotten
> > > > by malloc(). Does the memory get free automatically without
> > > > free() by the deamon  when the daemon process is killed?
> > > > Thanks in advance.
> > >
> > > It does, but in general its not in good practice to count on process
> > > exit for freeing memory (a good way to get memory leaks).
> >
> > This is incorrect.
> >
> > You shouldn't make an effort to return memory to the process' heap (by
> > calling free()) if the program is about to terminate.
> >
> > Doing so consumes CPU time (and probably disk bandwidth, given that
> > some of that memory will probably be swapped out) and doesn't provide
> > any benefit (free() won't usually return memory to the OS and, in any
> > case, all of the process' memory will be returned to the OS upon
> > exit).
> >
> > The only valid reason for free()ing memory blocks upon termination is
> > if the structure of the program is such that it isn't practical to
> > avoid doing so. E.g. if data structures have matched setup/cleanup
> > routines, and you need to call the cleanup code for other reasons, and
> > the cleanup code will free the memory anyway.
> >
> > Similarly, you don't need to explicitly close() file descriptors, or
> > release file locks (those obtained with flock/lockf/fcntl) as the OS
> > will do that.
> >
> > The sort of actions which might make sense to perform before calling
> > exit() are:
> >
> > + Writing a log entry reporting shutdown
> > + Deleting temporary files
> > + Deleting any SysV IPC structures which aren't shared with other
> >   processes.
> > + Informing other networked processes of termination, e.g. sending a
> >   "QUIT" command.
> > + Killing child processes.
>
> -
> To unsubscribe from this list: send the line "unsubscribe
linux-c-programming" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html