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

[Vlad K. <hv...@us...>]

> 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 ?

Regards,
Vlad