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

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

> 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.
 
> 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.
 
> You and Alex can still use yours refcounting, and in fact I'm still
> using them on my new why.cpp to fix existing problems.
> 
> But don't add it to our API, and we don't need it even if you want to
> use proxy objects in the engine.
> 
> It's just a mater of using it internally. Yvalve do refcounting and
> don't call methods on unallocated objects.

    How YValve objects will be protected ? See above.
 
> Engine proxies do whatever they need and don't call methods on
> unallocated objects.
> 
> But, please, add addRef/release to public API to prevent user from do
> mistakes at the price of do even more evil is not correct.

    What evil ? Wish to create robust API is an evil ? Than i'm devil's advocate ;)

Regards,
Vlad