[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [5.1.4/newbie] How to check end script?
- From: Sean Conner <sean@...>
- Date: Mon, 7 Mar 2011 12:14:57 -0500
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