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? Currently I see just one reason - error can't be reported. What if we find a way to report an error in such case? >> 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... > >> 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. ------------------------------------------------------------------------------ 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
