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.

> your justification to reference 
> counting. That damn "not crashing inside our code" said....
>
> For me the thing is finished. Arguments are valid only to support the 
> decisions already taken, and not the reality!
>

Please try to restrict yourself to techincal points.


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