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...
>> 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.
>
I'm just saying that "technical points" are not always considered. It's
considered and unconsidered by convenience. And it's *technically
explained* with the code I showed and your answear.
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
