Re: [Firebird-net-provider] Finalizers

[Jiří Činčura]

> In embedded or network part? In embedded I thought I had fixed that

In network. The embedded is OK - backed by the SafeHandles - as I wrote.

> issues. As for network, they should be eliminated at all IIRC.

Agreed. Although there might be a one or two cases where it makes sense,
higher up. I just have to review it and think carefully about all the
different cases I saw in last few years.

-- 
Mgr. Jiří Činčura
Independent IT Specialist

--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Finalizers

[zabulus12]

In embedded or network part? In embedded I thought I had fixed that issues. As 
for network, they should be eliminated at all IIRC.

Sent from my Windows 10 phone

From: Jiří Činčura--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Some guess or hint

[Jiří Činčura]

Too late. It's already solved. It was a race condition in Firebird
itself.

-- 
Mgr. Jiří Činčura
Independent IT Specialist

--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Finalizers

[Jiří Činčura]

> What finalizers are you mention?

All.

-- 
Mgr. Jiří Činčura
Independent IT Specialist

--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Some guess or hint

[Геннадий Забула]

I had catched such random issues by couple of tricks:
1. .trx files that were produced vstest.console. They always have call
stack with exception.
2. Unhandled exception handler that creates dump file of process
itself and then publish it as artifact. Dump can be opened in Visual
Studio, it will look as attached to process. Though I prefer using of
WinDbg

On 27 August 2016 at 10:28, Jiří Činčura  wrote:
> Hi *,
>
> I'm almost closing on compression support. It is stable when I run the
> tests on my machine. Multiple time, 32bit, 64bit. But are failing on
> AppVeyor.
>
> To make matters worse it's always different test(s). Check
> https://ci.appveyor.com/project/cincura_net/firebirdsql-data-firebirdclient/build/880
> or
> https://ci.appveyor.com/project/cincura_net/firebirdsql-data-firebirdclient/build/882
> . Only common piece is that it's always test with compression on (2nd
> parameter is True).
>
> I spent few days trying to guess what's wrong and fixing some things.
> But no final luck (I'll not list mine to not skew the thinking). So
> maybe some smart people here will have some idea.
>
> So let's open discussion. Or if you can make it fail on you machine,
> that would help as well.
>
> --
> Mgr. Jiří Činčura
> Independent IT Specialist
>
> --
> ___
> Firebird-net-provider mailing list
> Firebird-net-provider@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

Re: [Firebird-net-provider] Finalizers

[Геннадий Забула]

What finalizers are you mention?


On 29 August 2016 at 11:23, Gerdus van Zyl  wrote:
> I agree finalizers should not be used to mask or 'fix' incorrect provider
> usage. I try to avoid finalizers as much as possible since they run at
> unpredictable times causing hard to debug scenarios.
>
> On Sun, Aug 28, 2016 at 5:40 PM, Jiří Činčura  wrote:
>>
>> Hi *,
>>
>> Talking about finalizers in my last email. As I was getting through these,
>> I found few that are wrong-ish. In 99% cases failing with exception, that's
>> just swallowed. Confirmed from runtime. Although in 1% these might be lucky
>> I don't think it's correct usage.
>>
>> What the finalizers are mostly trying to do is something like close
>> connection gracefully with server or free some resources on server.
>>
>> And I believe this is wrong.
>>
>> First of all, this should be responsibility of developer to have correct
>> Dispose calls. Provider should not try to band aid it unless absolutely
>> necessary. Which brings me to the next point. The unmanaged resources, where
>> the finalizers make sense, are not something on server. We don't manage
>> that. Server should handle just fine when developer doesn’t close the
>> connection. Though some resources might be wasted. Unmanaged resources
>> directly allocated by provider are really a few around Embedded support
>> (mostly pointers and pieces of memory for marshalling). And these are
>> properly handled by SafeHandle. And finally finalizers introduce reentrancy
>> issues (anybody interested in details?) and it's really not correct in
>> provider as it grow out of hands.
>>
>> So in the foreseeable future I'll go through all of them and do massive
>> cleanup together with locking cleanup.
>>
>> It's probably going to cause some issues for some people, but their code
>> was wrong before, they were just "lucky".
>>
>> I believe it will make the code slightly faster and also solve some rare
>> bugs, often NREs from finalizer thread.
>>
>> Of course it will be new major version.
>>
>> --
>> Mgr. Jiří Činčura
>> Independent IT Specialist
>>
>>
>>
>> --
>>
>> ___
>> Firebird-net-provider mailing list
>> Firebird-net-provider@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>>
>
>
>
> --
> 
> Gerdus van Zyl
> www.infireal.com
>
> --
>
> ___
> Firebird-net-provider mailing list
> Firebird-net-provider@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>

--
___
Firebird-net-provider mailing list
Firebird-net-provider@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider