Client doesn't stop properly on .NET Core

[abdullin]

When shutting down the system, FoundationDB client tries to stop the network thread by aborting it. That isn't supported on .NET Core (at least on my mac), resulting in an exception:

Unhandled Exception: System.PlatformNotSupportedException: Thread abort is not supported on this platform.
   at System.Threading.Thread.Abort()
   at FoundationDB.Client.Fdb.StopEventLoop() in /Users/rinat/proj/fdb-layers/dotnet/foundationdb-dotnet-client/FoundationDB.Client/Fdb.cs:line 282
   at FoundationDB.Client.Fdb.Stop() in /Users/rinat/proj/fdb-layers/dotnet/foundationdb-dotnet-client/FoundationDB.Client/Fdb.cs:line 741
   at FoundationDB.Client.Fdb.<>c.<Start>b__46_0(Object sender, EventArgs args) in /Users/rinat/proj/fdb-layers/dotnet/foundationdb-dotnet-client/FoundationDB.Client/Fdb.cs:line 686

I see two problems here:

1. Can't use Thread.Abort (MSDN suggests using relying on cancellation tokens)
2. For some reason FoundationDB native thread (which is asked to stop) doesn't exit by itself.

[KrzysFR]

There are some issues with stopping the thread like you discovered, but there is even a bigger one: you can destroy the network thread once, but you cannot restart it in the same process after that.

This means that it is not really possible to stop/restart and the "official solution" way back then was to failfast the process. I think that the fdbserver employs this strategy (close all files, handles, and then the process will terminate itself) so they don't really have to deal with it.

There is also some issues in stopping with transactions still in flight (due to interop with the client library and registered callbacks that could still be invoked while the GC is shooting down everything left and right, including the callback itself or the Task themselves.

Until #48 is resolved, stopping the thread will still be problematic.

[KrzysFR]

I'm not exactly sure why the network thread is not starting. It waits 5 seconds before trying a Thread.Abort(), but I'm not even sure it would do much: it will only trigger once the execution comes back from native to managed (maybe on the next callback execution)?

It could be that the network thread is kept alive because there are still some transaction running?

It would be helpful to add a Debugger.Break() just before the call to Thread.Abort() and look at the different threads still active in the process.

[KrzysFR]

We've starting using .NET Core 3.0 and I haven't been able to reproduce this issue.

Maybe reopen if the issue still persists.