[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Unsubscribe
- From: "Brian A. Knudsen" <brian@...>
- Date: Wed, 30 Oct 2002 00:37:16 +0100
-----Oprindelig meddelelse-----
Fra: owner-lua-l@tecgraf.puc-rio.br
[mailto:owner-lua-l@tecgraf.puc-rio.br] På vegne af Thatcher Ulrich
Sendt: 29. oktober 2002 22:14
Til: Multiple recipients of list
Emne: Re: Garbage collection
On Oct 29, 2002 at 02:53 -0000, tom7ca wrote:
> [snip]
I think David answered your previous points better than I can; I just
want to pick up on the API issue...
> And reference counting is certainly not a good default allocation
> strategy for Lua because it's inefficient and a pain to use from a C
> API. Reference counting is probably the worst part of, for example,
> the Python implementation.
OK, that may well be true; I haven't used the Python API.
But, it seems to me that the existing Lua reference-locking API is
completely agnostic about how the internal Lua GC operates. See:
http://www.lua.org/manual/manual.html#5.14
Basically, a C program declares that it is interested in a particular
object, using the lua_ref() call. lua_ref() returns a integer handle,
for use in retrieving the reference. The C program calls lua_getref()
with the handle, to put the physical reference to the object on the Lua
stack. When the C program no longer needs access to that object, it
frees the handle using lua_unref().
No details about the underlying GC implementation are exposed; ref
counting can work just as well as anything else behind this interface.
--
Thatcher Ulrich
http://tulrich.com