 |
lua-l archive |
|
|
||
|
Thank you for the response. I'm a little bit annoyed because only theOn Sat, 26 Sep 2015 10:14:20 -0500
Javier Guerra Giraldez <javier@guerrag.com> wrote:
> On Sat, Sep 26, 2015 at 9:57 AM, Thierry <thi@thierry.1s.fr> wrote:
> > NOTE: it is mandatory to force the GC after the execution of some
> > Lua code because the allocated resources can be heavy and must be freed
> > ASAP.
>
>
> short answer: if you need to release resources deterministically (of
> even just eagerly), don't rely on GC. it's better to do a :close()
> method that you call as soon as you don't need your object.
>
>
> long answer:
>
> it is in the nature of GC that there's no guarantees of _when_ it will
> collect objects. on some languages, it's a stated goal to be as eager
> as possible, sometimes even resorting to reference counting despite
> all its known drawbacks; this is not the case in Lua, where GC tries
> to do as little work as possible, and objects can (and do) remain in
> memory for a long time after not being referenced anywhere.
>
> the Lua GC is driven by "memory pressure", but it doesn't have any
> access to C pointers, or other resources. the userdata objects are
> treated as black boxes, and they are accounted only for their declared
> size. In many cases, a userdata object is only a pointer to the real
> data, so it exerts extremely low "pressure".
>
> it's possible to have many of these very small objects, the rest of
> the system is choking full of malloc()ated memory, lots of files open,
> and the Lua VM is totally "too bad, not my problem, I only have these
> thousands of tiny objects".
>
>
> oh, and about handling errors: yes, Lua doesn't have a 'finally'
> clause, like it doesn't have 'try...catch', but it's not hard to
> implement either with pcall(). it's not just for "dangerous code",
> it's also quite good to get the chance to release resources.
Lua knows the usage of my variable.
In brief, my program associated file descriptor to an Lua abject. If
the user forgot to close the fd, and cannot close because an error
occurs, I expect that the GC function __gc() close it. A challenge is to
close the fd as soon as possible for prevent memory leaks.
I called functions executed in a coroutine. Maybe the developper copy
the object containig the FD in the global env, or maybe not. It cant
know this information, so I can't close himself the fd. Only the gc and
the refcount system (I guess) know the information.
I resolve my issue forcing a full garbage collection cycle after each
functions using these type of object (I detect the object creation).
Maybe a quick __gc() of some object call will be welcome. it may be
declared with anything like "__mode" = "q" (similar of weak
references) ?
Maybe it have another way to known the usage of a variable ?
Thierry