Re: [Firebird-net-provider] Finalizers

2016-08-29 Thread 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


Re: [Firebird-net-provider] Finalizers

2016-08-29 Thread 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

2016-08-29 Thread 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