Re: [Firebird-devel] Providers, yvalve, external engines and object lifecycle

[Alex P. <pes...@ma...>]

 On 03/28/11 23:22, Adriano dos Santos Fernandes wrote:
> On 28-03-2011 15:28, Vlad Khorsun wrote:
>>>>> The user should not call detach and another methods simultaneously,
>>>>> never. Why the heck they would do it? This is user application problem.
>>     Do you offer us to undo thread-safety changes made in v2.5 client library ? :)
>>
> I believe you're too optimistic about thread-safety. No bug reports may
> not means no problem, it may be because nobody tries to crash "inside
> our code".
>

Must say that I had a number of bug reports from Dmitry Kovalenko, an
authot and maintainer of .NET IB provider. He has a very serious test
suite for his provider, and certainly when something fails in underlying
code he reported that errors. And they were fixed.

> Do you really think that isc_dsql_prepare and isc_dsql_free_statement
> are thread safe when both used concurrent in a same statement handle?
>
> This is a question open to finalize my changes.
>
> Do we really need to allow simultaneous calls on the same attachment in
> yvalve, since they're going to be blocked (serialized) in another
> (remote - not sure, engine - sure) providers?
>

Adriano, as far as I remember you were the author of one change in
engine code making it possible to have simultaneous calls on the same
attachment. It was on SAS request.

The fact that calls are serialized now in engine does not mean that we
are not planning to (may be) make them run in parallel sometimes in the
future. Moreover, detach is already not strictly serialized - it can
abort running requests and close database. Therefore I think we must
have API ready for simultaneous calls.

> If we say yes, we must do it correct, but current and 2.5 code doesn't
> look like to be.

Agreed. But it does not mean we must stay in that bad state as long as
possible.