lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


It was thus said that the Great Daniel Silverstone once stated:
> On Mon, Mar 07, 2011 at 05:32:28PM +0100, Axel Kittenberger wrote:
> > >  Both do the job, but os.exit() will cause the process to end immediately
> > > without the garbage collector doing a final clean up.  I found this out the
> > > hard way when I had some code that would flush a file and close it when the
> > > object was garbage collected, but calling os.exit() would leave the file in
> > > an inconsistent state.  Doing a 'return' from the script would cause the GC
> > > to kick in.
> > 
> > I suppose you had some extra on "__gc"? I always believed the Linux
> > kernel will call a clean close() on all open file descriptors when
> > terminating a process.
> 
> Assuming these are file descriptors created with io.open or io.popen then they
> have C-library FILE* objects backing them.  These can hold writes in memory
> until they need to be flushed, are flushed explicitly, or are closed with
> fclose().  No amount of kernel-based cleanup will help with that :-)

  (I've yet to receive Axel's email, so I'm replying to this)

  Well, the actual use case was:

	read file into in-memory representation, then close file.
	manipulate the data
	on __gc, open the file and write the updates.

  And it wasn't a FILE *, but it was a userdata object (a custom format for
a series of records sorted by a single key).  I had a __index and __newindex
method defined (both integer and string based indicies) and while I could
have looked for the "close" index, or had a separate function to explicitely
write the data, I felt it was okay to just use the __gc method to handle
that.

  So, yes, I did have some extra stuff on the __gc method.

  -spc