> On 05/16/11 23:47, Vlad Khorsun wrote:
>>> On 16/05/2011 14:12, Vlad Khorsun wrote:
>>>>> On 16/05/2011 13:33, Vlad Khorsun wrote:
>>>>>> So, if code calls attach\release - this is bug, as for me, and i see
>>>>>> no reasons
>>>>>> to write code in this way intentionally. I consider at as very bad
>>>>>> practice as it
>>>>>> could lead to the inexpected side effects (such as implicit rollback).
>>>>>>
>>>>> Now every provider class has a way to "release" with another methods,
>>>> Again, "release" it not how object should be finally destroyed. It is
>>>> for
>>>> additional references *only*.
>>>>
>>> This is something new you invented.
>> You asked about semantics and i explained how i understand it. If you
>> have
>> something technical against it - show it here and we'll decide what to do.
>>
>
> Vlad, let's start with the following - why is calling release() to
> remove last reference is bad?
Because it opens a way to make bugs - rolled back work, for example.
> Currently I see just one reason - error can't be reported. What if we
> find a way to report an error in such case?
What error do you mean ? At previous message you said that release() could
be called if detach() failed. Do you see a problem if release() also will fail
? Or
you talk about something else ?
>>> IFirebirdConf and IPluginConf, for example. They're released with release.
>> IPluginConf is not constructed explicitly from the user POV - it is
>> created
>> by the Firebird and passed into user code, see :
>>
>> IPluginFactory::createPlugin(IPluginConfig* factoryParameter), where
>>
>> user is implemented IPluginFactory interface.
>>
>> IFirebirdConf also not constructed by user request as it is obtained via
>> method of IPluginConfig instance passed above :
>>
>> IFirebirdConf* IPluginConfig::getFirebirdConf()
>>
>> If you ask me why attach() and getFirebirdConf() is different - the
>> answer
>> is : by semantics. And by presence explicit "destructor" function.
>
> Vlad, I'm afraid that this difference is not enough precise...
attach() constructed object for *my private use* and i'm responcible for
*destroying* it after use.
getFirebirdConf(), in general, could return some *common* object instance
and i can't destroy it - i just must *release* it after usage.
Difference between "destoy" and "release" is semantics. I don't know how
to explain it else.
>>> The situation with new classes trying to be smart using reference
>>> counting is still almost unexplained from the POV of why that was done.
>>>
>>> Sure you may create artificial and specific examples of where they make
>>> things to not crash.
>>>
>>> But nothing except an atomic counter is currently being cared regard
>>> MT-safeness. Y-valve has internal state not synchronized, for example.
>>> Y-valve delegates call to another providers, and they do nothing re.
>>> died objects to return information.
>> This is still work in progress, i think. Probably Alex have better
>> answer.
>
> In FB2.5 yValve did not need any more MT-safeness except provided by
> atomic counters and some helper locks like hanlers' map RwLock.
> Initially I've planned to keep same approach for FB3. But I did not
> review latest Adriano's changes from this POV.
I think we still have what to do to make code and interfaces more clear
for end users. This is why i said that it is work in progress.
Regards,
Vlad
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
