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, 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!
Adriano
------------------------------------------------------------------------------
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
