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

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

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.

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.

>>> Why not?
>>> User has background thread which on the regular basis performs some
>>> actions with database. When database is close, that thread must close. I
>>> think this is not user application problem, but a problem of API,
>>> suggested not taking into an account MT specifics.
>>>
>>>> Users are supposed to know basic how-to-work with pointers, otherwise
>>>> they don't even can get a pointer to the object. If they want to crash
>>>> the local system you can do nothing about it.
> 
>     We can't prevent crash in user code, yes. But we must prevent crash in our code, always. 
> Even if we got crazy wrong input parameters. And in reality we already have all necessary 
> syncronization around handles, sockets, etc. So, why force user to repeat the same code 
> making applications less efficient ?
> 
>>> Sometimes I can. With reference counted objects. At least I can help
>>> them to not crash when it can be avoided.
>>>
>> Yes, you can. We can do everything, that don't mean it's the right choice.
>>
>> Support (which the cost of spoil an API) a user mistake about detaching
>> an attachment and having concurrent threads calling functions on it and
>> hiding or throwing another errors in destructors is sure a wrong choice.
> 
>     Nobody going to hide errors. With refcounting at proxy objects concurrent thread will receive 
> isc_bad_XXX_handle error, instead of crash. Should i said that destructor will not throw ? :)
> 
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.

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.

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.


Adriano