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 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 I did
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 it
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
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 ...
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.
I
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
memory
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 we use
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 we use
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 implemented so
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 implemented so
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
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
13 matches
Mail list logo
