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