On 05/18/11 15:24, Adriano dos Santos Fernandes wrote:
> On 18/05/2011 08:05, Alex Peshkoff wrote:
>>   On 05/18/11 14:49, Adriano dos Santos Fernandes wrote:
>>> On 18/05/2011 03:53, Alex Peshkoff wrote:
>>>>    On 05/17/11 19:34, Adriano dos Santos Fernandes wrote:
>>>>> On 17/05/2011 04:05, Alex Peshkoff wrote:
>>>>>> In FB2.5 yValve did not need any more MT-safeness except provided by
>>>>>> atomic counters and some helper locks like hanlers' map RwLock.
>>>>>> Initially I've planned to keep same approach for FB3. But I did not
>>>>>> review latest Adriano's changes from this POV.
>>>>>>
>>>>> I already show you that 2.5 yvalve is not thread safe. Once more.
>>>>>
>>>>> How do you expect this code to work concurrently?
>>>>>
>>>>> --------------
>>>>>            Statement statement = translate<CStatement>(stmt_handle);
>>>>>
>>>>>            statement->checkPrepared();
>>>>>            sqlda_sup::dasup_clause&   clause =
>>>>> statement->das.dasup_clauses[DASUP_CLAUSE_select];
>>>>>
>>>>>            if (clause.dasup_info_len&&   clause.dasup_info_buf)
>>>>>            {
>>>>>                iterative_sql_info(    status,
>>>>>                                    stmt_handle,
>>>>>                                    sizeof(describe_select_info),
>>>>>                                    describe_select_info,
>>>>>                                    clause.dasup_info_len,
>>>>>                                    clause.dasup_info_buf,
>>>>>                                    dialect,
>>>>>                                    sqlda);
>>>>>            }
>>>>> --------------
>>>>>
>>>>> Accessing same memory, extending internal buffers, etc.
>>>> Good point, but I did not mean abuse of API. I only wanted to say that
>>>> under normal circumstances there are no race conditions that may cause
>>>> server to segfault/hang.
>>>>
>>> Under *normal circumstances* nobody is going to *abuse* the API freeing
>>> a handle and using it at the same time,
>> Sorry, unfortunately this may happen under normal circumstances:
>> 1. When one is using 'delete from mon$....' table.
>> 2. When shutdown is started.
>>
> And I said many times this didn't require ref counters to work. In fact 
> must more clear solutions was possible, but...
>

Yes, certainly - they may be replaced by mutexes. But atomic counters
(base of ref counters) are faster.

BTW - I certainly agree that initial point (dasup_clause) should be fixed.


------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its 
next-generation tools to help Windows* and Linux* C/C++ and Fortran 
developers boost performance applications - including clusters. 
http://p.sf.net/sfu/intel-dev2devmay
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to