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

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

>>> 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 ? :)

>> 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 ? :)

Regards,
Vlad