Re: [Firebird-net-provider] Finalizers

[zabulus12]

What cases? Problem of finalizers that all managed objects you try to reference 
must be treated as null. If you try to look from this view you'll see that 
theyre don't do anything

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] 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] 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] 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

Re: [Firebird-net-provider] Finalizers

[Gerdus van Zyl]

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

Re: [Firebird-net-provider] Finalizers

[Jiří Činčura]

> A forecast in time for this release

Hopefully before end of the year. My current plan, among bug fixes, is
roughly: compression > .NET Core > EF Core > finalizers.

-- 
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

[Norbert Saint Georges]

> 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.

that is my opinion also.
A forecast in time for this release

-- 
Norbert Saint Georges
http://tetrasys.fi


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

[Firebird-net-provider] Finalizers

[Jiří Činčura]

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