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

[Adriano d. S. F. <adr...@gm...>]

On 24-03-2011 12:50, Alex Peshkoff wrote:
>  On 03/24/11 18:07, Adriano dos Santos Fernandes wrote:
>> On 24-03-2011 11:56, Alex Peshkoff wrote:
>>>> You see, reference counting alone don't solve the user problem.
>>> When used wrong - yes, do not. But if:
>>>
>>> T1: globalObj->addRef();
>>> T1: start T2 /* that's using globalObj */
>>>
>>> It's OK. BTW, it's present in MS docs - "You must also call AddRef on a
>>> pointer before passing it ....".
>>>
>> Reference counting is overloaded to make this work. 
> 
> Sorry, it's just words...
> 
>> With a single atomic
>> variable user fix the problem without need a polluted API.
>>
> 
> Reference counter is really not more than atomic counter.
> 
>> It's user responsibility to use pointers before free them, and I showed
>> you can't fix user mistakes.
> 
> Certainly not. I never pretended to fix user mistakes.
> What can be done - is help to avoid them. And providing functions,
> familiar to many people in other products, is good way to do it.
> 
> I do not understand what do you want to show. You say that use of
> refcounted API is polluted and overloaded. But it is used in IT world,
> and it is used actively. Even forgetting OLE2 - OOO is also using it.
> Before saying "I want to suggest something new" it's very good idea to
> look around - what do other people do? And before calling everything you
> do not like for some reason 'ugly, polluted and overloaded' try to
> explain - why?
> 

This is from wikipedia:

"One primary motivation for reference counting in COM is to enable
interoperability across different programming languages and runtime
systems. A client need only know how to invoke object methods in order
to manage object life cycle; thus, the client is completely abstracted
from whatever memory allocator the implementation of the COM object
uses. As a typical example, a Visual Basic program using a COM object is
agnostic towards whether that object was allocated (and must later be
deallocated) by a C++ allocator or another Visual Basic component.
However, this support for heterogeneity has a major cost: it requires
correct reference count management by all parties involved. While
high-level languages like Visual Basic manage reference counts
automatically, C/C++ programmers are entrusted to increment and
decrement reference counts at the appropriate time. C++ programs can and
should avoid the task of managing reference counts manually by using
smart pointers. Bugs caused by incorrect reference counting in COM
systems are notoriously hard to resolve, especially because the error
may occur in an opaque, third-party component.
Microsoft has abandoned reference counting in favor of tracing garbage
collection for the .NET Framework."

I would add that COM dates 1990 decade, and reference counting is
abandoned in new environments. Do I suggest we add garbage collection to
Firebird API? Of course, no. I'm just saying we should add nothing there
as there are nothing to care about. And we known the first paragraph is
solvable by simple "disposable" approach.

> I agree that there may be other methods to make pointers stable in MT
> world. One of them is to say - we do not care about this, it's user
> responsibility. As for me it's much better to have required support (and
> pay attention - traditional for interfaces). Certainly, if you can
> suggest other approach, which does not let people make errors - let's go
> with it. But please make it not limited with C++ only.
> 
As also said in the wikipedia snippet, it's difficult to make reference
count work manually, in languages like C and non-C++ languages expected
to use our API. You also said about user don't need to call it, as then
only a single release is going to destroy the object. So, we're adding
nothing except a complication. I prefer much more things that consistent
fail in dev environment than ones that works in dev and may fail in
production.

Do you like counters and they solve internal problems in good way, go on
and use them. But this is not necessary and is evil in our API.

> Currently I prefer to stay with traditional reference counters because:
> 1. They are familiar to a lot of programmers - just say 'please work
> with fb3 handles like OLE2 objects when MT safety is needed', and at
> least 70% of people will understand what you mean.
> 2. They do what they are supposed to do - help people work with our API
> in MT safe way.
> 3. They are very simple to implement.
> 
You list only the "pros". What about the cons: they are obsolete (1990),
complicated (without smart pointers), bugged (reference cycles) and
unnecessary (as I showed in my example, user still need to care when an
object is live).


Adriano