[Firebird-devel] Reference counters in API - was Re: Providers, yvalve, external engines and object lifecycle

[Alex P. <pes...@ma...>]

 We have too many problems in single thread. I try to divide it to
smaller parts.
The first one - here we at least all seem to talk about same thing:-) -
is to use reference counters or not.

On 03/28/11 22:45, Adriano dos Santos Fernandes wrote:
> User should *not* request a detachment and then request actions on the
> objects. This *is* user application problem, no mater it being single or
> multi thread.

In that case our new API is regression compared with old ISC API with
handles. Pre FB3 an attempt to request actions on the objects after
detachment cause correct reply from client library - invalid handle.
Without reference count support we will get segfault in FB3. I treat
this as serious regression.

> You and Alex can still use yours refcounting, 

They are not our :-) Could one of us be an authors of such great solution!

> and in fact I'm still
> using them on my new why.cpp to fix existing problems.
>
> But don't add it to our API, 

As one of users replied: Object-based interfaces should use the
refcount. I and Vlad totally agree with him.

Let's  look at use of refcount in API from 3 different points of view:
languages that support smart pointers (C++, Delphi), languages that
perform GC themselves (.Net platform is a good sample) and old-stylers
like plain-C.

In the first case people are free to make a choice. If they wish, they
use smart pointers to API objects. Also they may forget about reference
counters, and write as if there is no such functions at all,
synchronizing access to API objects themself. IMHO manual control
(calling addRef/release when needed) is not good idea for such languages.

What about high-level case - end-users just never see raw API. Solution
how to work with API will be taken by people, who write
connectors/providers/etc for that platforms. We know what IB .net
provider author thinks about it.

In the third case (though telling true it's too brave to start MT
project on such language) people can synchronize access to API objects
themselves, as if there is no reference counters at all. Or use them -
it's there choice. For example: method to call a kind of dtor when
thread terminates do exist, calling addRef when is also not too hard
task, therefore who knows what will be more reliable.

Reference counters really have one big problem - when used incorrectly,
related bugs are hard to fix. But missing them can sometimes cause even
more serious problems. Therefore we (I and Vlad) suggest to give people
freedom of choice regarding this problem. If someone wants to use them -
we must provide that support. If not - everyone is free to provide his
own synchronization.