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

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

On 30-03-2011 07:41, Vlad Khorsun wrote:
>> On 28-03-2011 15:28, Vlad Khorsun wrote:
>>>>>> The user should not call detach and another methods simultaneously,
>>>>>> never. Why the heck they would do it? This is user application problem.
>>>
>>>     Do you offer us to undo thread-safety changes made in v2.5 client library ? :)
>>>
>> This has *nothing* related, as 2.5 has no public objects, only handles,
>> and nothing in 3.0 changes about it.
> 
>     Seems you never saw such issues. You are happy ;)
>  
>> 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.

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

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

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

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

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

Same question as above, but in the contrary order, what about relation
of child to parents?

>> 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.


Adriano