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

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

 On 03/29/11 18:11, Dimitry Sibiryakov wrote:
> 29.03.2011 15:45, Alex Peshkoff wrote:
>> 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 can't avoid segfaults if you are going to reveal pointers in API at all. No matter 
> whether this is pointers to objects (as in proposed API) or structures (as in original GDS 
> design). No way for refcounters can prevent use of invalid pointers. Call of 
> (IAttachment*)(123456)->AnyRoutine() will crash.

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.

I must say that this is not artificial theoretical problem. We had that
kind of races in yValve in firebird 2.5 before internal objects
(CAttachment, CTransaction, etc.) were not made reference counted and
pointers to them were not made smart. 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?