What finalizers are you mention?
On 29 August 2016 at 11:23, Gerdus van Zyl <gerdusvan...@gmail.com> 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 <j...@cincura.net> 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
