Re: [Firebird-devel] Providers, yvalve, external engines and object lifecycle

[Adriano d. S. F. <adr...@gm...>]

On 25-03-2011 09:05, Alex Peshkoff wrote:
> 
> BTW, smart pointers is a kind of trivial GC mechanism, are not them?
> 
C++ users don't need you adding addRef/release to let them control
object life via smart pointers. Boost has a lot of smart pointer
classes, and one would just use it (or write one) if needed.

> 
> If some language does not support smart pointers in any form, it's
> certainly hard to use it for MT programming.
> Most popular for today (C++ and Delphi) support them. All that's needed
> is to have a trivial wrapper around refCounted object.
> 
And the wrapper could be the smart pointer itself. No need to have it on
our API.

> 
> And this is just wrong statement. Without reference counters in API
> objects support for MT safety in user program (which as far as I
> remember you suggest people implement themself) becomes much more
> complicated.
> 
And you're not fixing MT problems at the necessary levels, because it
need user attention. (my example again)

> Let's suppose that user implemented some helper around IAttachment*,
> which is not refCounted as you wish. Please explain, how must behave
> that object when detach is requested, but there are some other threads,
> using that object.
> 
Let me first say something about your refcounted approach:

Current, when an user detachs and attachment, all handles related to it
and not-yet-freed are closed.

Let say you did the same when calling IAttachment::detach. Then your
refcount don't work, cause it will wipe pointers to objects with references.

Let say it don't free the subobjects. Then you're making a common
situation (close a parent -> close children) to leak memory.

Now about your question, more directly. If this thread is doing
something inside the yvalve, the detach may (*internally) decrement a
refcounter and don't free the object, so we don't see a crash inside the
yvalve. As soon the yvalve release this reference, the object is wiped.

Note we don't need any effort to support this. As soon we remove
addRef/release from IInterface, we can make YAttachment and friends to
inherit from RefCounted and IAttachment and friends.

So I insist, moving addRef/release to the API fixes nothing and only
complicate things. Transactions has no release, it's freed by
commit/rollback. Attachments has no release, it's freed by detach/drop.
There is no reason to insert a release function in them that sometimes
do a thing (decrement a refcounter) and sometimes do another (rollback
or detach).


Adriano