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.
Adriano
PS: There is a paper
(http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf) from Scott
Meyers and Andrei Alexandrescu showing even or volatile usage in base
classes are wrong. Unfortunately it's down.
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
