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

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

On 30-03-2011 07:32, Vlad Khorsun wrote:
>> 30.03.2011 11:56, Alex Peshkoff wrote:
>>> Dmitry, please do not mix artificially created pointers (BTW, why so
>>> complex example with 123456? 0 will cause crash too.) with pointers,
>>> that were correct, but were destroyed in another thread. Your sample
>>> shows an error in the program. On the other hand, access to a pointer
>>> that was correct, but became invalid, is rather typical case when
>>> dealing with MT program.
>>
>>   There is no difference. Whether pointer was invalid from the beginning or become, 
>> result is the same. 
> 
>     Your example is a crash in *user* code, not in ours. 
> 
>> AFAIU, you want to protect API latter with reference counter, but it 
>> will work only in correctly written programs. But such programs work correctly without 
>> reference counters. So, what's the point?
> 
> 
>     Reference counting prevents MT races in most cases, it is already used by our code 
> internally and allows user to not add additional locking layer for MT safety.
> 
>>> Dmitry Kovalenko watched 'invalid
>>> handle value' error in his IB provider. What else arguments do you need
>>> to let people use API with protected from disappearance pointers?
>>
>>   I'd like to be sure that such protection will have any advantage over current abstract 
>> handles. So far I don't see in proposals any difference from current design, so I don't 
>> understand the purpose of changes.
> 
> 
>     Handles always checked before dereferencing. It have its cost both in memory usage and
> CPU instructions.
> 
>     Interface pointers needs no implicit checks by our code because it will crash in user code 
> when VMT is accessed. 
> 
>     Do you see the difference ?
> 
If user pass an invalid pointer parameter, it *will* crash in our code:

provider->attachDatabase((Status*) 0x1, (char*) 0x1, ...);

We can't prevent wrong program from crashing in our code. The same is about:

freedObject->something();


Adriano