Finalizers

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Finalizers

Jiří Činčura-2
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers

Norbert Saint Georges-2
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers

Jiří Činčura-2
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers

Gerdus van Zyl
In reply to this post by Jiří Činčura-2
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider




--
------------------------------------------------------------------------
Gerdus van Zyl

------------------------------------------------------------------------------

_______________________________________________
Firebird-net-provider mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
zab
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers

zab
What finalizers are you mention?


On 29 August 2016 at 11:23, Gerdus van Zyl <[hidden email]> 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 <[hidden email]> 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
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>>
>
>
>
> --
> ------------------------------------------------------------------------
> Gerdus van Zyl
> www.infireal.com
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Firebird-net-provider mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
>

------------------------------------------------------------------------------
_______________________________________________
Firebird-net-provider mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers

Jiří Činčura-2
> What finalizers are you mention?

All.

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

------------------------------------------------------------------------------
_______________________________________________
Firebird-net-provider mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
zab
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers

zab

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: [hidden email]
Sent: Tuesday, September 6, 2016 6:53 PM
To: [hidden email]
Subject: Re: [Firebird-net-provider] Finalizers

 

> What finalizers are you mention?

 

All.

 

--

Mgr. Jiří Činčura

Independent IT Specialist

 

------------------------------------------------------------------------------

_______________________________________________

Firebird-net-provider mailing list

[hidden email]

https://lists.sourceforge.net/lists/listinfo/firebird-net-provider

 


------------------------------------------------------------------------------

_______________________________________________
Firebird-net-provider mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers

Jiří Činčura-2
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider
zab
Reply | Threaded
Open this post in threaded view
|

Re: Finalizers

zab

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: [hidden email]
Sent: Tuesday, September 6, 2016 7:59 PM
To: [hidden email]; [hidden email]
Subject: Re: [Firebird-net-provider] Finalizers

 

> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/firebird-net-provider