[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: tolua++ porting to 5.2
- From: William Ahern <william@...>
- Date: Tue, 15 Jan 2013 15:50:56 -0800
On Wed, Jan 16, 2013 at 07:13:36AM +1100, Ross Bencina wrote:
> On 15/01/2013 4:34 PM, William Ahern wrote:
<snip>
> >In any event, the process of adding reference counting--examining and
> >analyzing object lifetimes--would undoubtedly improve the quality of the
> >codebase generally.
>
> I would question whether adopting reference counting everywhere would
> "improve the quality of the codebase generally." I do agree that
> adopting a disciplined set of resource management policies is critical.
> Reference counting is one of the tools available.
I tend to agree. I meant implementing reference counting for those objects
which are bound in Lua. I only implement reference counting for certain
shared objects. In regular C code it's rare; by Lua is the canonical example
of indeterminate ownership where reference counting is the obvious solution.
> One reason I like C/C++ (compared to GC languages) is that I am in full
> control of object lifetimes. This makes things predicatble. Often the
> unique ownership pattern (eg. std::unique_ptr) is enough, and means that
> you don't need reference counting (and the associated overhead). Don't
> get me wrong, I do selectively use reference counting, but only when the
> object lifetime/usage patterns require it.
>
> Also, extensive use of RAII in C++ means that deterministic destruction
> is required for correct operation in many cases.
Thus the reference counting.
I implement RAII patterns in C almost religiously. The only difference
compared to C++ is that I have to be explicit about object destruction when
exiting a scope.
> In the case of Lua bindings we have a mismatch between managed lifetime
> semantics (a lot of C++ code) and non-deterministic finalisation (Lua
> GC). You're proposal is to always put Lua in control of object lifetimes.
Yes. IMO, it's the simplest and sanest solution.
> One way to think about it is that we're talking about is "how do we
> implement safe weak-references to C/C++ objects from Lua?"
>
> Whether a Lua binding should use weak references is certainly up for
> discussion. But when it is needed (and I assert that it is, sometimes)
> then it would be good to know what the available options are.
I'm going to suggest that it really shouldn't be up for discussion ;) Of
course there are exceptions where reference counting won't work. But
exceptions always have very specific contexts, and it's those contexts which
will invariably constrain and define the solution.
> There seem to be two main approaches we've considered:
>
> - Use a memory-block version counter so that Lua can poll for object
> validity.
> - Hook object deletion or destruction to invalidate the "weak
> references" (stored in a hash table or linked structure).
>
> The version counter is efficient and elegant, but not failsafe unless
> you can ensure that: (a) the memory is never unmapped, and (b) the
> version counter field is never overwritten (consider larger
> reallocations after heap coalescing).
Any solution which invokes undefined behavior is not a solution. Or rather,
it's as good a solution as just turning the computer off.