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
