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

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

 On 03/24/11 17:17, Adriano dos Santos Fernandes wrote:
> On 24-03-2011 11:08, Alex Peshkoff wrote:
>>  On 03/24/11 16:50, Adriano dos Santos Fernandes wrote:
>>> On 24-03-2011 06:14, Alex Peshkoff wrote:
>>>>  On 03/23/11 17:29, Adriano dos Santos Fernandes wrote:
>>>>>> Adriano, are you serious that all described here is simpler than proxy
>>>>>> objects in engine? :-)
>>>>>>
>>>>> I'm *sure* it is. I showed you ~15 lines of code, against
>>>>> addRefs/releases around by Firebird and all-over-the-world users code.
>>>> Most of addRef/release in firebird are done using smart pointers.
>>>> Therefore this is not a problem.
>>>>
>>> Of course it is. Currently why.cpp is completely unnecessarily
>>> overloaded by RefPtrs, References, etc. I'm rewriting it in much simple way.
>>>
>> Adriano PLEASE do not hurry too much.
>> We still have no decision on a problem...
>>
> It's does not include remotion of your beloved refcounters... :) yet.
> It's just new implementation, a simple (it don't need to not be)
> framework to use the providers in more modern way.
>
>>>> What about users code - if user is not going to use an object in complex
>>>> MT environment he need not care about reference counters at all. May be
>>>> you did not pay attention, but detach, commit and all other calls,
>>>> closing handle, perform release automatically on successful completion.
>>>>
>>>> In MT environment existing inside exported object reference counters
>>>> will just help to minimize user code - remember your own words that if
>>>> someone needs MT safety he will have to completely implement logic
>>>> himself without reference counters?
>>>>
>>> Please let me know, with details, what *user* problem you want to solve
>>> making *user* call addRef in his MT program.
>> Big desire to recommend you to read microsoft's com-related
>> documentation :-)
>> In 2 words problem is as follows - avoid segfault when pointer to
>> already non-existing interface is used.
>>
> Alex, how (or better saying, what)? What problem are you solving from
> user POV?
>
> Please let me know what type of usage of addRef will solve users
> problems, and what problems are these.

Well, an example.

I have database attachment and want to use it in some background thread.
Attachment may be closed at some random moment. I have a choice - check
some flags before each use of it (and anyway have problems - may be it
was closed at some point before that check and actual use) or add
reference to it and use without risk of segfault. Certainly, I must
check status vector after each operation, and after getting 'invalid
handle value' return from the thread. But checking status is anyway good
style, therefore with reference counter in attachment handle I write
code for that thread as if I'm the owner of an attachment. And I'm
really one of it's owners after addRef() call!