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