Support for CERs

[Kukkimonsuta]

Split from dotnet/runtime#14419

Are CERs going to be supported or is there viable alternative?

Recorded uses in (3rd party) libraries:

• LibGit2Sharp

[sharwell]

The ReliabilityContract attributes could probably be removed without any other changes when targeting a framework that doesn't support them.

I would think CriticalFinalizerObject already exists since it's the base class of SafeHandle. However, if it doesn't the use of it in LibGit2Sharp could probably be rewritten using CriticalHandle instead. This would actually apply to all builds and not just be a special consideration for CoreCLR.

[joshfree]

@jkotas can you comment on CERs

[jkotas]

CERs were primarily invented for SQL CLR, to ensure that user code cannot leak or otherwise damage the SQL process. The runtime was required to recover from OOM or thread abort in any spot.

We gave up on providing this level of robustness for .NET Core runtime and framework because of it is incredibly expensive to code and test for:

• Thread abort is not supported in .NET Core.
• OOM is on fail-fast plan: When the process hits OOM or similar exception in a bad spot, it will be terminated. It is consistent with the cloud programming patterns: When designing for cloud, one should assume that the process can be killed any time without warning, etc.

Porting guidance:

• CERs should be stripped when porting to .NET Core: CriticalFinalizerObject replaced with regular Object, CER attributes removed, etc.
• Places in the program where the cleanup is required to happen – and the program cannot safely continue if it does not - should be either left as unhandled exception that terminates the process, or wrapped with try { ... } catch { Environment.FailFast(...); }.

If CERs are frequent problem to deal with for porting large amounts of code, we can consider creating CER compat pack for CoreCLR with dummy implementation.

[Kukkimonsuta]

Thank you for the explanation, I believe there is nothing to add and this issue can be closed.