[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Closing the Lua state before exiting
- From: Sean Conner <sean@...>
- Date: Mon, 9 Feb 2015 21:59:35 -0500
It was thus said that the Great Coda Highland once stated:
> On Sun, Feb 8, 2015 at 10:37 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> > 2015-02-09 7:59 GMT+02:00 Daurnimator <quae@daurnimator.com>:
> >> On 9 February 2015 at 00:53, Dirk Laurie <dirk.laurie@gmail.com> wrote:
> >>> The manual for `os.exit` states:
> >>>
> >>> If the optional second argument close is true, closes the Lua state before
> >>> exiting.
> >>>
> >>> 1. Why would one want to do this?
> >> To ensure all resources are cleaned up correctly.
> >> This may mean cleaning closing connections to servers, etc.
> >>
> >>> 2. Why would one not want to to do this every time?
> >> If you know there are no resources to be cleaned up and want to exit fast.
> >
> > Would it then not be a good habit to wrap os.exit so that the Lua state
> > is closed in the case of normal termination unless explicitly specified
> > otherwise? I..e. `close` defaults to `code`?
> >
>
> I think the "default" use of os.exit is a hard abort when the
> application has entered an unrecoverable state and needs to bail out
> as quickly as possible. Using something as brute-force as os.exit and
> still wanting to run the cleanup is faintly smelly.
On a POSIX system, exit() does quite a bit of clean up, EXIT_SUCCESS or
EXIT_FAIULRE notwithstanding. Yes, it does run any code registered with
atexit(), but it also flushes any unwritten data to open FILE*s and closes
them.
_exit() (or _Exit()) is a bit more abrupt---it make the exit system call,
leaving the kernel to close any open file descriptors and reclaim memory
(i.e. _exit() jumps directly into the kernel; no other user code is run
after that point).
I personally, don't see os.exit() closing the Lua state as smelly. Yes,
by convention, a return code of 0 is success, other values indicate an
error, but a non-0 value can still convey information (see
/usr/include/sysexits.h on most POSIX systems). And one can still exit in a
clean and orderly way. If I want brute-force, don't bother with any user
clean up, I'd use _exit() (but I'm usually using POSIX systems anyway).
As for Lua closing/not closing the Lua state on os.exit(), I've been
bitten by this (in Lua 5.1) more times that I care to remember. At work,
a userdata I created dumps itself to a file when garbage collected, and
plenty of times I've written scripts with a call to os.exit(0) only to not
file an expected file.
-spc