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

[Vlad K. <hv...@us...>]

>>> I'm just saying that we should not protect users from using unallocated
>>> objects at a price of adding confusing and non-needed functions in our API.
>> 
>>     I don't agree with "confusing and non-needed functions". It is not technical and
>> even not an argument.
>>  
> First, you and Alex would need to explicit define what's the semantics
> of release, which is not even deductible by the current trunk.

    Current trunk have known errors in this regards and can't be used as example.

    Rule is simple - release() should decrement reference counter. When counter became
zero, object is deleted phisycally. Physical delete should call logical delete if object is in 
active state (disconnect, rollback, etc).
 
> What would do a release in a live (not detached / not committed / etc)
> object when refcount > 1?

    Decrement refcount
 
> What would do a release in a live (not detached / not committed / etc)
> object when refcount = 1?


    Decrement refcount and delete object. Destructor (or separate function such as destroy()) 
will call detach\rollback on real object, if needed. 

> What would do a detach/commit/etc in an object when refcount > 1?

    Call corresponding method of real object. And not touch refcount. 
 
> What would do a detach/commit/etc in an object when refcount = 1?

    Same as above.

> Would parents (say attachment is parent of statement) will do
> statement->addRef/release or not?

    Yes. For example, attachment could have array of smartpointers with statements and 
in desroy() it will assign NULL's into every item.
 
> Same question as above, but in the contrary order, what about relation
> of child to parents?

    Child's destroy() will ask parent to unregister itself on destroy. If parent already destroying
it will not found such child and it will be ok.

    All above is well known and easy to implement techniques.
 
>>> User should *not* request a detachment and then request actions on the
>>> objects. This *is* user application problem, no mater it being single or
>>> multi thread.
>> 
>>     If *we* will crash with application it will be *our* pain and loss of *our* reputation.
>>  
> As I said, there are others ways to wrong application do this.

    We should separate our pointers and user-defined pointers (strings, etc). Else i can
complain that program don't work after i filled random memory regions with garbage ;)

Regards,
Vlad