On 05/18/11 15:24, Adriano dos Santos Fernandes wrote:
> On 18/05/2011 08:05, Alex Peshkoff wrote:
>> On 05/18/11 14:49, Adriano dos Santos Fernandes wrote:
>>> On 18/05/2011 03:53, Alex Peshkoff wrote:
On 05/17/11 19:34, Adriano dos Santos Fernandes wrote:
> On 17/05/2011 04:05, Ale
On 18/05/2011 08:05, Alex Peshkoff wrote:
> On 05/18/11 14:49, Adriano dos Santos Fernandes wrote:
>> On 18/05/2011 03:53, Alex Peshkoff wrote:
>>>On 05/17/11 19:34, Adriano dos Santos Fernandes wrote:
On 17/05/2011 04:05, Alex Peshkoff wrote:
> In FB2.5 yValve did not need any more
On 05/18/11 14:49, Adriano dos Santos Fernandes wrote:
> On 18/05/2011 03:53, Alex Peshkoff wrote:
>> On 05/17/11 19:34, Adriano dos Santos Fernandes wrote:
>>> On 17/05/2011 04:05, Alex Peshkoff wrote:
In FB2.5 yValve did not need any more MT-safeness except provided by
atomic counter
On 18/05/2011 03:53, Alex Peshkoff wrote:
> On 05/17/11 19:34, Adriano dos Santos Fernandes wrote:
>> On 17/05/2011 04:05, Alex Peshkoff wrote:
>>> In FB2.5 yValve did not need any more MT-safeness except provided by
>>> atomic counters and some helper locks like hanlers' map RwLock.
>>> Initiall
On 05/18/11 03:25, Vlad Khorsun wrote:
>> On 17-05-2011 19:58, Vlad Khorsun wrote:
PS: There is a paper
(http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
Meyers and Andrei Alexandrescu showing even or volatile usage in base
classes are wrong. Unfortuna
On 05/17/11 19:34, Adriano dos Santos Fernandes wrote:
> On 17/05/2011 04:05, Alex Peshkoff wrote:
>> 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
On 05/16/11 21:00, Vlad Khorsun wrote:
> We can introduce some special mode to report such errors using exceptions,
> or write message into log, or even provide callback for debugging purposes.
>
> But Adriano's question was about *semantics*. So, do you agree with me
> that
> explicit d
> On 17-05-2011 19:58, Vlad Khorsun wrote:
>>> PS: There is a paper
>>> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
>>> Meyers and Andrei Alexandrescu showing even or volatile usage in base
>>> classes are wrong. Unfortunately it's down.
>>
>> With MSVC we are s
On 17-05-2011 19:58, Vlad Khorsun wrote:
>> PS: There is a paper
>> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
>> Meyers and Andrei Alexandrescu showing even or volatile usage in base
>> classes are wrong. Unfortunately it's down.
>
> With MSVC we are safe as w
> PS: There is a paper
> (http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
> Meyers and Andrei Alexandrescu showing even or volatile usage in base
> classes are wrong. Unfortunately it's down.
With MSVC we are safe as we use "volatile" and compiler used read\write
me
On 17/05/2011 04:05, Alex Peshkoff wrote:
> 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.
>
> Hey Vlad, you already made your excellent job of misrepresent a
> technical discussion into personal one. Congratulations.
Thanks. Do you have something else to say ? From technical side, please.
...
> See, providers was committed a lot of time ago. The implementation of
> (only) *refere
On 17/05/2011 09:13, Alex Peshkoff wrote:
> On 05/17/11 16:07, Vlad Khorsun wrote:
>>> To support wrong code and solve nothing. With the cost of all this mess,
>>> all this otherwise unneeded discussion, all the global/local pool mess.
>> ...only emotions and offence...
>>
Hey Vlad, you alre
On 05/17/11 16:07, Vlad Khorsun wrote:
>> To support wrong code and solve nothing. With the cost of all this mess,
>> all this otherwise unneeded discussion, all the global/local pool mess.
> ...only emotions and offence...
>
Agreed - nothing except emotions ...
> Speaking about documentation i'd said we must document usage of every
> public
> interface and specify explicitly how instance is constructed and destroyed.
>
Well - with this adjustment I can agree with every style.
(Though must say that addRef/release pair in our interfaces is already
f
>>> the following way - if refCounter> 1, no error happened (later it
>>> always means that nothing like system call failed took place). If
>>> refCounter == 1 and object has no special dtor, again no error happened.
>> If object have no explicit destructor then release must be called, no
>>
On 17/05/2011 08:27, Vlad Khorsun wrote:
>> What about the following - we always pass status vector to release().
> I'm sorry but i against it. addRef\release is and well known pair and its
> usage also well known. I see no good reason to change it. More, if we
> need to change it, then we use
> What about the following - we always pass status vector to release().
I'm sorry but i against it. addRef\release is and well known pair and its
usage also well known. I see no good reason to change it. More, if we
need to change it, then we use it in a wrong way.
> It's not a problem techni
On 05/17/11 11:41, Vlad Khorsun wrote:
>> 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 th
> 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 ba
> On 05/16/11 21:00, Vlad Khorsun wrote:
>>
>> We can introduce some special mode to report such errors using
>> exceptions,
>> or write message into log, or even provide callback for debugging purposes.
>>
>> But Adriano's question was about *semantics*. So, do you agree with me
>> that
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
>>>
On 05/16/11 21:00, Vlad Khorsun wrote:
>
> We can introduce some special mode to report such errors using exceptions,
> or write message into log, or even provide callback for debugging purposes.
>
> But Adriano's question was about *semantics*. So, do you agree with me
> that
> explicit
> 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 inexp
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 si
> 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).
>>
> N
> On 05/16/11 20:33, Vlad Khorsun wrote:
>>> Could you explain, please, semantics of addRef/release on public
>>> provider interfaces?
>>>
>>> The issue was discussed on this list with two possibilities:
>>> - when refCount = 1, release does things like detach, rollback, free,
>>> etc. It's what
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 p
On 05/16/11 20:33, Vlad Khorsun wrote:
>> Could you explain, please, semantics of addRef/release on public
>> provider interfaces?
>>
>> The issue was discussed on this list with two possibilities:
>> - when refCount = 1, release does things like detach, rollback, free,
>> etc. It's what was imp
> Could you explain, please, semantics of addRef/release on public
> provider interfaces?
>
> The issue was discussed on this list with two possibilities:
> - when refCount = 1, release does things like detach, rollback, free,
> etc. It's what was implemented so far.
> - sometime mentioned also
30 matches
Mail list logo
